Adobe Target 26.10: Safari Support and Reporting Fixes

Adobe shipped two Target Standard/Premium releases in October 2026, 26.10.1 on 13 October and 26.10.2 on 15 October. The headline is that Target is now supported in the Safari browser, with a catch: the Visual Experience Composer and Enhanced Experience Composer still are not. The rest is a set of fixes that matter if you rely on Analytics for Target reporting, saved reporting presets, or live Recommendations activities.

Key takeaways

• Safari is now a supported browser for Target, but the Visual Experience Composer (VEC) and Enhanced Experience Composer do not run in it. Authors still need Chrome.
• Reporting presets saved on an activity were being deleted after about two weeks. That is fixed, but check which presets you have lost.
• A4T activities on a newly added report suite could fail to show results. That is fixed too.
• Editing a promotion in a live Recommendations activity could spawn new promotions and recommendation units with no change in definition. Audit what your activities created.
• These are mostly corrections. Verify them quickly, brief your team, and move on.

What changed in the 26.10.1 and 26.10.2 releases

The 26.10.1 release, dated 13 October 2026, carried two fixes. The first covers Analytics for Target: activities using a newly added report suite showed a Something went Wrong error in the Target report instead of results, and the View in Analytics link produced an incompatible report suite message with missing classification information. The second sits in the VEC, where the Modifications panel showed raw HTML instead of the offer name when an Experience Fragment was delivered through an mbox.

The 26.10.2 release, dated 15 October 2026, had four items. The Activity Overview page now shows the goal settings correctly. Before, a goal could display with https:// added to the page URL and without the URL contains condition, even though the real configuration was right. Editing a promotion in a live Recommendations activity no longer creates new promotions and recommendation units when nothing changed. Saved reporting presets are no longer deleted after roughly two weeks. And Safari support arrived, with an overlay in the VEC telling Safari users to switch to Chrome.

Adobe's page was last updated on 16 October 2026 and also flags a deprecation of the Target UI version toggle, pointing to its own FAQs. It gives no further detail in the text, so read that FAQ before assuming anything about timing.

None of this touches your delivery code. There is no at.js or Platform Web SDK change in these two releases, which keeps the risk low.

Safari support: what it does and does not change

The wording is easy to misread. Target is supported in Safari, meaning the Target interface can be used there. The VEC and the Enhanced Experience Composer are not supported in Safari, and the editor now shows an overlay that tells users to open Chrome instead.

So what actually changes? For people who review activity setup, check reports, read the Overview page, approve activities or manage audiences, Safari is now a legitimate browser to do that in. A marketer on a MacBook no longer has to wonder whether a quirk is their browser's fault. For people who build visual experiences, nothing changes. Chrome remains the authoring browser.

That split suggests a simple internal rule: any task that opens the composer happens in Chrome, everything else is fair game anywhere Adobe lists as supported. Write that into your onboarding doc. The overlay will say it too, but a sentence in the wiki saves a support ticket.

One thing to be careful about. Safari support for the Target interface says nothing about how your visitors' Safari browsers treat cookies, storage or tracking. That is a separate, longstanding topic for your implementation, and these releases do not alter it. Do not read this note as a statement about visitor-side behavior.

Who should care most? Design and content teams that live on Apple hardware, agencies whose staff are Mac-heavy, and QA people who like to check reports on whatever machine is nearest. Everyone else can skim.

Reporting and Analytics for Target fixes

Two of the fixes sit in the reporting path, and they are the ones most likely to have cost someone time.

The A4T failure is the more visible. If you added a report suite recently and built an A4T activity against it, you may have opened the report and hit an error with nothing to read. Clicking through to Analytics then complained about an incompatible report suite because the Analytics for Target classification information was missing. Release 26.10.1 resolves that. If you worked around it by switching to a different suite or by pulling numbers straight from Analytics, you can go back to your intended setup, but confirm it on one activity first.

The preset issue is quieter and arguably worse. Reporting presets are the saved views analysts build for an activity: the metric choices, the audience or experience filters, the comparisons. If those were deleted after about two weeks, an analyst could have rebuilt the same view several times without knowing why. The fix means new and existing presets should now stay put. Adobe's text does not say that deleted presets are restored, so treat any preset you had two or three weeks ago as potentially gone and check.

The Overview goal display is cosmetic in that the underlying goal configuration was correct, but it caused reviewers to doubt a setup that was fine, or worse, to edit a correct goal to match what the page showed. If anyone changed a goal because the Overview looked wrong, review that change.

Recommendations: check what your live activities generated

This is the fix with the most potential for cleanup work. Before 26.10.2, editing a promotion inside a live Recommendations activity could make Target create new promotions and new recommendation units even though nothing in their definition had changed. The release notes title calls these backup recommendations displayed after a promotion is updated.

In practice that means a team that tweaked promotions on a live activity regularly could have a library cluttered with duplicates. Duplicates are annoying for naming and housekeeping, and they raise the question of which unit a given activity is actually serving from. The fix stops new ones appearing. It does not, on the evidence of the text, remove the ones already created.

A reasonable cleanup pass:

1. List the live Recommendations activities that had promotions edited in recent months.
2. For each, compare the promotions and recommendation units attached with your naming conventions and expected counts.
3. Identify look-alike entries with identical definitions that you did not knowingly create.
4. Confirm which ones an activity actually references before deleting anything.
5. Retire the unused ones, and record what you removed and why.

Do not bulk-delete on the assumption that anything unfamiliar is a leftover. Plenty of teams have legitimate near-duplicates with different criteria or fallback content.

Who should act, and what to do

The table below maps each change to the people it touches. Treat the action column as a checklist, not a project.

Change	Who it affects	Action	Effort
Safari supported, VEC and Enhanced Experience Composer not	Reviewers, analysts, anyone using Target on a Mac	Tell the team: Chrome for the composers, other browsers for the rest	Minutes
A4T error on newly added report suites	Analytics and optimization leads	Reopen an affected activity, confirm results load and View in Analytics works	Under an hour
Reporting presets deleted after about two weeks	Analysts with saved views	Inventory presets, re-save the important ones	An hour or two
Overview goal settings displayed wrongly	Activity approvers and QA	Re-check any goal that was edited because it looked wrong	Under an hour
Promotion edits creating extra promotions and units	Personalization and Recommendations owners	Audit live activities, retire confirmed duplicates	A few hours
Experience Fragment name shown as raw HTML in the Modifications panel	Authors using Experience Fragments through an mbox	Open an affected activity, confirm the offer name displays	Minutes

If you run Target as a small team, the owner of the whole list is probably one person. If you have a central optimization group with separate analytics and personalization owners, assign the A4T and presets work to analytics and the Recommendations audit to personalization.

How to test and roll out the checks

There is nothing to deploy, so the work is verification in your live environment. Sequence it so the findings are useful.

Start with reporting, because the result is quickest. Pick one A4T activity on a recently added report suite and open its report. Then use View in Analytics. If both work, note the activity and date in your change log. If either fails, capture the exact message and activity ID, and check the Experience League documentation and Adobe support channels before raising a ticket.

Next, presets. Ask each analyst to list the presets they depend on, then save a fresh one on a live activity today and note the date. Look again in three weeks. That is the only way to confirm the two-week deletion is gone in your own account. Put a reminder in a shared calendar; this is the kind of check people forget.

Then Recommendations. Do the audit above on a staging or low-traffic activity first if you have one, and make a deliberate no-change edit to a promotion to see whether new objects appear. If none do, the fix is working for you.

Finally, the Experience Fragment display. Open an activity that delivers a fragment through an mbox and look at the Modifications panel. You should see the offer name and not code. This is a presentation fix, so the risk is small, but it is the sort of detail that confuses a new author.

No phased rollout is needed. If you do keep a written release log for Target, add one line per item with the verification date.

How to measure that it worked

These fixes do not move conversion, so do not look for a lift. Measure whether the friction disappeared.

• Report load success: Can your analysts open A4T reports on every active report suite without an error? Track exceptions in a simple tally for a month.
• Preset persistence: Are presets saved today still there after three weeks? One yes or no per analyst.
• Object hygiene: Does the count of promotions and recommendation units on a live activity stay flat after routine edits? Record the count before and after.
• Support volume: Do internal questions of the form my report is broken or my view disappeared drop off?

If you cannot get a clean answer from the interface, ask whoever owns the Adobe relationship to check the specifics with Adobe, since the public text only describes the symptom and the fix.

Where a partner helps and where you can do it yourself

Most of this is in-house work. Telling the team about Safari, re-saving presets, and checking an A4T report need no outside help, and paying for it would be wasteful.

The Recommendations audit is the borderline case. If your account has dozens of live activities and years of accumulated promotions, a partner who knows how your criteria and naming were set up can move faster and avoid deleting something in use. The same applies if your A4T problems turn out to run deeper than the fixed bug, for example if report suites, classifications and merchandising variables were never aligned. That is an implementation question and not a release-note question.

If you are weighing outside help for those reasons, the Adobe Target partners directory and the ranked Adobe Target partner list are good places to start comparing. When you are ready to brief someone, the Adobe Target RFP template gives you a structure for scope, access and success measures so the first call is not spent defining basics.

A fair test of a partner here: ask how they would verify the A4T path on a new report suite before an activity goes live. A good answer is specific. A vague one is a warning.

What not to do

Don't treat Safari support as a reason to move authoring off Chrome. The composers are the part that is not supported, and Adobe has put an overlay in the editor precisely to stop people trying.

Don't assume lost presets are recoverable. Rebuild the ones that matter and move forward.

Don't delete promotions and recommendation units in bulk because they look duplicated. Confirm what each live activity references first, and keep a record.

Don't open a project for this. Six small items, one afternoon of checking, one note to the team. That is the right size.

And don't ignore the deprecation of the Target UI version toggle that Adobe flags on the same page. The text points to a dedicated FAQ and gives no further detail, so read that FAQ, find out whether anyone on your team still depends on the older view, and plan accordingly. Anything beyond that is guesswork until Adobe says more.

Sources

• Adobe Experience League: Target release notes — Target Standard/Premium 26.10.1 (13 October 2026) and 26.10.2 (15 October 2026); page last updated 16 October 2026.