Migrating Adobe Target from at.js to Web SDK: A Practical Guide

Why Migrate from at.js to Web SDK

Adobe has been clear about the direction: Web SDK (alloy.js) is the future of data collection across the Adobe Experience Platform ecosystem. While at.js still works and receives security patches, all new features and integrations are built for Web SDK first.

The practical reasons to migrate now:

• Single library — Web SDK replaces at.js, AppMeasurement, and the Visitor ID Service with one tag. Less JavaScript, fewer network calls, faster page loads.
• Server-side decisioning — Web SDK supports on-device decisioning for Target, which eliminates the flicker problem entirely for qualifying activities.
• AEP integration — If you’re using or planning to use CJA, AJO, or Real-Time CDP, Web SDK is required. Running at.js alongside these creates identity resolution conflicts.
• Datastream architecture — Web SDK sends data to a single Adobe Edge endpoint. Routing to Target, Analytics, and AEP happens server-side, reducing client complexity.

Pre-Migration Checklist

Before touching any code, audit your current Target implementation:

1. Inventory all activities — Export a list of every active and scheduled A/B test, XT activity, AP activity, and Recommendations campaign. Note which use the Visual Experience Composer (VEC) vs form-based composer.
2. Document custom code offers — Any activity using custom JavaScript or CSS in offers needs special attention. These often reference at.js-specific functions like adobe.target.getOffer() or adobe.target.applyOffer().
3. Check mbox usage — List all regional mboxes and any custom mbox names. Web SDK uses “scopes” and “surfaces” instead of mbox names, but there’s a mapping layer.
4. Review response tokens — If you’re using response tokens for analytics integration or custom reporting, document which tokens are in use.
5. Profile scripts and audiences — Verify that your profile scripts and any audiences using Target-specific parameters will work post-migration.

Datastream Configuration

The datastream is the server-side routing configuration that replaces the client-side library routing in at.js.

In the Adobe Experience Platform UI:

1. Create a new datastream (or edit an existing one if you’re already using Web SDK for Analytics).
2. Add the Adobe Target service to the datastream.
3. Configure the Target property token — this maps to your Target workspace.
4. Enable or disable the Target response token settings as needed.
5. If using on-device decisioning, set the decisioning method to “hybrid” or “on-device” depending on your activity types.

The property token in the datastream replaces the at_property parameter you may have been passing in at.js targetPageParams.

Implementation Approach

There are two main paths: tag-managed (via Adobe Launch) or direct implementation.

Launch-Managed Migration

If you’re using Adobe Launch (Tags), this is the cleaner path:

1. Install the Web SDK extension in your Launch property.
2. Configure the extension with your datastream ID, organization ID, and edge domain.
3. Create a “Send Event” rule that fires on page load. Set the renderDecisions flag to true to automatically apply VEC-based Target activities.
4. Migrate custom code offers — Replace at.js trigger rules with Web SDK sendEvent calls using the appropriate decision scopes.
5. Remove the at.js extension once migration is validated.

Direct Implementation

For sites without Launch, you’ll swap the library reference:

// Remove: at.js script tag
// Add: alloy.js
alloy("configure", {
  datastreamId: "YOUR_DATASTREAM_ID",
  orgId: "YOUR_ORG_ID@AdobeOrg"
});

// Page load -- replaces target-global-mbox
alloy("sendEvent", {
  renderDecisions: true
});

For form-based activities with named scopes:

alloy("sendEvent", {
  decisionScopes: ["my-custom-scope"]
}).then(function(result) {
  // Handle propositions manually
  const propositions = result.propositions;
  // Apply offers to the page
});

Validation and QA

After migrating, validate every active Target activity:

• VEC activities — Load the page, confirm the experience renders without flicker, check that the correct experience is served based on audience targeting.
• Form-based activities — Verify that decision scopes return the expected offers and that your rendering logic applies them correctly.
• Activity QA links — Use Target’s QA mode to force specific experiences and verify each variation.
• Analytics integration — Confirm that A4T (Analytics for Target) reporting still receives data. The reporting source may need reconfiguration if you’re switching from at.js A4T to Web SDK’s automatic Analytics integration.

Common Pitfalls

• Flicker management — at.js has a built-in prehiding snippet. Web SDK requires a separate prehiding style that you manage. Don’t skip this or VEC activities will flash the default content before rendering.
• Mbox naming — Web SDK uses the scope name __view__ for the page-load target-global-mbox equivalent. Don’t create activities targeting target-global-mbox as a scope name.
• Order of operations — alloy("configure") must complete before any sendEvent call. In Launch, the extension handles this. In direct implementations, ensure the configure call is synchronous.
• SPA handling — For single-page apps, you need to call sendEvent with renderDecisions: true on each virtual page navigation, not just the initial load.

The migration is not a weekend project for a complex implementation, but it’s also not as risky as it sounds if you approach it methodically. Start with a staging environment, migrate one property at a time, and validate each activity before moving to the next.