Adobe Target Sample Size Calculator and AI Insights Beta

Adobe Target release 26.9.8, dated 30 September 2026, adds two beta features that sit on either side of an experiment: a Sample size calculator for planning before launch, and AI insights for learning from a finished A/B test. Both are beta, so they are worth a trial rather than a rollout. The same release also fixes a permissions bug that would have stopped many admins from letting anyone try the AI feature in the first place.

Key takeaways

• Release 26.9.8 (30 September 2026) adds a beta Sample size calculator and beta AI insights to Adobe Target Standard and Premium.
• The calculator helps you estimate traffic, test duration, number of experiences or minimum detectable effect before you launch.
• AI insights applies to A/B Test activities with Manual traffic allocation, and only after the experiment reaches statistical significance.
• Product Admin and System Admin users could not grant AI permissions until this release fixed the Unauthorized error (TGT-56261).
• Trial both on a handful of activities, compare against your own method, and keep your current test governance in place.
• The earlier September 2026 releases are mostly fixes; scan them for anything you have been working around.

What does Adobe Target 26.9.8 add?

Two features, both labelled beta in the notes, and one administration fix.

The Sample size calculator is reached from the Activities menu. Per the notes, it uses the inputs you give it to estimate the traffic required, the test duration, the number of experiences, or the minimum effect you can reliably detect. In other words, you fix some of those variables and it solves for another.

AI insights is aimed at the other end of the lifecycle. For A/B Test activities with Manual traffic allocation, once an experiment reaches statistical significance, it highlights attributes of the winning experience that likely contributed to its performance. It also suggests opportunities: new experience ideas, hypotheses and implementation guidance intended to help improve conversion rates.

The administration fix is the quiet one. Users with Product Admin and System Admin access could not grant AI permissions to other users. Trying to enable the AI permission produced an Unauthorized error even when AI was enabled for the organization. That is now resolved.

Nothing in the notes says these features change how Target serves experiences or counts conversions. They sit around the test, not inside the delivery path. That keeps the risk of trying them low.

How should you use the sample size calculator in test planning?

Use it at the point where a test idea becomes a ticket. That is where most programmes quietly lose rigour.

Here is the situation it addresses. A product team wants to test a new checkout layout, a stakeholder wants an answer in two weeks, and nobody has asked whether two weeks of traffic on that page can detect anything smaller than a large swing. Teams without a planning step tend to stop tests when the chart looks good, which is how false winners get shipped.

A calculator built into the Activities menu moves that conversation to where the activity is being created. The four things it can solve for are the useful part:

• Traffic needed: how many visitors the test requires for the effect you care about.
• Duration: how long that traffic takes to arrive on your actual pages.
• Number of experiences: how many variants your traffic can support before each one is starved.
• Minimum effect: the smallest lift you could reliably see, given the traffic and time you have.

The fourth is the most honest. If a page gets modest traffic, the answer may be that you can only detect large changes. That is a reason to test bolder ideas or pick a higher-traffic page, not a reason to run an underpowered test anyway.

Check the detailed documentation for the exact fields and how it treats things like your baseline conversion rate. Because it is beta, run your next few planned tests through it and through whatever method you use today. If the numbers agree, you have lost nothing. If they differ, find out why before trusting either.

What does AI insights tell you, and where does it stop?

It reads a finished result and offers a view on why the winner won. That is useful and also easy to over-trust.

The scope is narrow on purpose. It applies to A/B Test activities with Manual traffic allocation. If your programme leans on Auto-Allocate, Auto-Target or Automated Personalization, the notes do not say AI insights covers them, so don't assume it does. It also waits for statistical significance, so it won't comment on a test that is still running.

What comes out is a set of attributes of the winning experience that likely contributed, plus ideas, hypotheses and implementation guidance. Read the word likely carefully. An attribute that correlates with a win in one test isn't proven to cause it. A button colour, a shorter headline and a moved form field may all have changed in the same variant, and no summary can separate them without a follow-up test.

So the right use is as a source of next hypotheses. Take a suggestion, write it down as a hypothesis with a predicted direction, and test it. The wrong use is pasting the generated explanation into a results deck as if it were the finding.

A practical example: a retail team wins a test where the variant had a shorter product description and a stronger delivery message. AI insights might point at one or both. The team's job is to run a follow-up that isolates them, not to roll the two changes into every template.

Who needs to act on the AI permissions fix?

Anyone who tried to give a colleague AI access and hit an error. Everyone else can skim.

The bug was specific. Product Admin and System Admin users saw an Unauthorized error when enabling the AI permission for another user, even though AI was enabled for the organization. Adobe lists it under TGT-56261 in the 26.9.8 notes.

If you have a ticket open about this, or a workaround where one person with broader rights does the grants, you can now retire it. The order of work is:

1. Decide who should see AI insights. Start with the experimentation lead and one or two analysts, not the whole user list.
2. Have a Product Admin or System Admin grant the AI permission to those users.
3. Confirm the permission shows correctly for each person and that the feature appears for them.
4. Record who has it, so a later access review has something to compare against.

There is a governance point here. AI-generated suggestions can influence what a team builds next. Limiting the permission at first keeps that influence with people who understand experiment design.

What else shipped in the September 2026 releases?

The rest of the page is mostly fixes. They are small individually, but a few remove workarounds teams have been carrying. This table maps each to who is likely to feel it.

Release and date	Change	Who it affects	Suggested action
26.9.8, 30 September 2026	Beta Sample size calculator and AI insights; AI permission fix	Experimentation leads, analysts, admins	Trial on a few activities; grant AI access to a small group
26.9.7, 28 September 2026	Fix for an Invalid user input error when saving and closing a Recommendations activity in the Visual Experience Composer	Teams editing Recommendations activities	Retest saving an activity that failed before
26.9.6, 24 September 2026	Fix for an endless redirect loop in the Visual Experience Composer on SSO-authenticated pages	Sites behind a login flow	Retry loading those pages in the composer
26.9.5, 21 September 2026	Fix for a missing A4T report link in the Target UI; content pre-hiding reached General Availability	A4T users; teams managing page flicker	Check the Reports section for affected activities
26.9.4, 17 September 2026	Fix for the Insert Before control being out of reach for Experience Fragments on the top-most page element	Teams using Experience Fragments	Retest the affected placements
26.9.3, 16 September 2026	Fix for blank Lift and Confidence in some A4T Auto-Target reports; Reporting Source now read-only for live activities without Analytics access	A4T Auto-Target users	Re-open affected reports before quoting numbers
26.9.2, 8 September 2026	Fix for feed URL encoding in the new interface; Automated Segments report attribute display	Recommendations and personalization teams	Recreate any failed feed; recheck segment reports
26.9.1, 1 September 2026	Fix for copying an activity with an activity-only audience; Recommendations tools added to the Adobe Target MCP server (Public Beta)	Teams copying activities; Premium Recommendations tenants	Retry the copy; see the notes on MCP requirements

The reporting fixes are the ones to take seriously. If an A4T Auto-Target report showed blank Lift and Confidence, anyone who worked around it with a manual calculation should re-check that those numbers match the corrected report. The Recommendations MCP tools need a Recommendations-enabled tenant with Target Premium and are not available on non-Premium accounts, so most teams can ignore that item.

How do you trial the two betas without disrupting live testing?

Keep the trial small, dated and reversible. Neither feature changes delivery, so the real risk is process drift, not broken pages.

A sensible plan for a four-to-six week trial:

1. Pick three upcoming tests of different sizes. Run each through the calculator during planning and note the traffic and duration it gives.
2. Run your usual method alongside. Write both estimates in the test brief, so the comparison exists before the result does.
3. Choose two or three finished A/B tests with Manual allocation that reached significance, and review what AI insights says. Compare it with what your analysts concluded independently.
4. Hold a short review. Where did the tool add something you missed? Where was it vague or wrong?
5. Decide the rule. For example: the calculator is required in every brief, and AI insights is optional input to hypothesis generation.

One thing not to do is switch your approval gates around on the strength of a beta. If your testing governance says a named analyst signs off the sample size, that stays. The calculator's output becomes one more input to that person.

Also keep the beta status visible. Anything described as beta can change in behaviour, scope or availability. Write that into your internal documentation so nobody builds a mandatory process on something that may shift.

How do you measure whether these features are helping?

Measure the programme, not the feature. A few signals tell you more than usage counts.

• Share of tests with a documented plan. If the calculator is working, more activities should have a recorded traffic and duration estimate before launch.
• Tests stopped early. Track how many tests end before their planned duration. The number should fall as planning improves.
• Inconclusive rate. Underpowered tests tend to end without a clear answer. A falling rate suggests better planning, though seasonality and traffic shifts will muddy it.
• Hypothesis quality. For AI insights, count how many suggested hypotheses made it into the backlog, and how many of those produced a significant result when tested.
• Time from result to next test. If insights shorten the gap between a win and the follow-up, that is a real gain.

Don't expect a clean before-and-after. Programmes change for many reasons at once. Look at direction over a quarter and be willing to say it was inconclusive.

I'd also keep one counter-measure: track any case where a suggestion sounded plausible and the follow-up test showed no effect. Those cases are the best protection against over-reliance.

Where does an implementation partner help, and where can you go it alone?

Most of this is within a competent team's reach. Turning on permissions, running the calculator, reading the results and holding a review needs no outside help.

A partner earns their fee in three places. First, if your programme has no real planning discipline, building one (briefs, power thinking, sign-off, a results library) takes experience and some political weight. Second, if you run Analytics for Target and your reports have been showing gaps, a partner can audit the activities and data collection to confirm the corrected reports line up with your numbers. Third, if you are weighing a wider move into personalisation or Recommendations, they can scope it honestly.

If you are looking for one, the Adobe Target partners directory is a starting point, and the Adobe Target RFP template helps you write a brief that asks for testing-programme work specifically instead of generic implementation. More release coverage is on the MarTech Partners blog.

What to avoid: paying for a bespoke AI strategy around two beta features. The notes describe a calculator and an insight panel. That is not a transformation project.

The short version: grant access to a few people, put the calculator into your next three test briefs, review AI insights against your own conclusions, and leave your approval process where it is until the betas have earned a place in it.

Sources

• Adobe Experience League — Adobe Target release notes (current), last updated 1 October 2026, covering releases 26.9.1 to 26.9.8.