What is the difference between at.js 1.x and at.js 2.x workflow diagrams?
See Upgrading from at.js 1.x to at.js 2.x for more information on the differences that were introduced in 2.O from 1.x.
From a high level view, there are a couple of differences between the two versions:
- at.js 2.x does not have a global mbox request concept but rather a page-load request. A page-load request can be viewed as a request to retrieve content that should be applied on the initial page load of your website.
- at.js 2.x manages a concepts called Views, which are use for Single Page Applications (SPAs). at.js 1.x is not aware of this concept.
at.js 2.x diagrams
The following diagrams help you understand the workflow of at.js 2.x with Views and how this enhances the SPA integration. To get a better introduction of the concepts used in at.js 2.x, see Single Page Application implementation.
(Click image to expand to full width.)
| Step | Details |
|---|---|
| 1 | Call returns the Experience Cloud ID if the user is authenticated; another call syncs the customer ID. |
| 2 | The at.js library loads synchronously and hides the document body. at.js can also be loaded asynchronously with an optional prehiding snippet implemented on the page. |
| 3 | A page load request is made including all configured parameters (MCID, SDID, and customer ID). |
| 4 | Profile scripts execute and then feed into the Profile Store. The Store requests qualified audiences from the Audience Library (for example, audiences shared from Adobe Analytics, Audience Manager, etc.). Customer attributes are sent to the Profile Store in a batch process. |
| 5 | Based on URL request parameters and profile data, Target decides which activities and experiences to return to the visitor for the current page and future views. |
| 6 | Targeted content is sent back to the page, optionally including profile values for additional personalization. Targeted content on the current page is revealed as quickly as possible without flicker of default content. Targeted content for views that are shown as a result of user actions in a SPA is cached in the browser so it can be instantly applied without an additional server call when the views are triggered through triggerView(). |
| 7 | Analytics data is sent to Data Collection servers. |
| 8 | Targeted data is matched to Analytics data via the SDID and is processed into the Analytics reporting storage. Analytics data can then be viewed in both Analytics and Target via (A4T) reports. |
Now, wherever triggerView() is implemented on your SPA, the Views and actions are retrieved from cache and shown to the user without a server call. triggerView() also makes a notifications request to the Target backend in order to increment and record impression counts. For more information on at.js for SPAs with Views, see Single Page Application implementation.
(Click image to expand to full width.)
| Step | Details |
|---|---|
| 1 | triggerView() is called in the SPA to render the View and apply actions to modify visual elements. |
| 2 | Targeted content for the view is read from the cache. |
| 3 | Targeted content is revealed as quickly as possible without flicker of default content. |
| 4 | Notification request is sent to the Target Profile Store to count the visitor in the activity and increment metrics. |
| 5 | Analytics data sent to Data Collection Servers. |
| 6 | Target data is matched to Analytics data via the SDID and is processed into the Analytics reporting storage. Analytics data can then be viewed in both Analytics and Target via A4T reports. |
Video - at.js 2.x architectural diagram
at.js 2.x enhances Adobe Target’s support for SPAs and integrates with other Experience Cloud solutions. This video explains how everything comes together.
See Understanding how at.js 2.x works for more information.
at.js 1.x diagram
The following diagrams help you understand the workflow of at.js 1.x.
(Click image to expand to full width.)
| Step | Description | Call | Description |
|---|---|---|---|
| 1 | Call returns the Experience Cloud ID (MCID) if the user is authenticated; another call syncs the customer ID. | 2 | The at.js library loads synchronously and hides the document body. |
| 3 | A global mbox request is made including all configured parameters, MCID, SDID, and customer ID (optional). | 4 | Profile scripts execute and then feed into the Profile Store. The Store requests qualified audiences from the Audience Library (for example, audiences shared from Adobe Analytics, Audience Manager, etc.). Customer attributes are sent to the Profile Store in a batch process. |
| 5 | Based on the URL, mbox parameters, and profile data, Target decides which activities and experiences to return to the visitor. | 6 | Targeted content is sent back to page, optionally including profile values for additional personalization. The experience is revealed as quickly as possible without flicker of default content. |
| 7 | Analytics data is sent to Data Collection servers. | 8 | Target data is matched to Analytics data via the SDID and is processed into the Analytics reporting storage. Analytics data can then be viewed in both Analytics and Target via Analytics for Target (A4T) reports. |
Personalization & Experiementation Excellence with Recommendations and AI
Adobe Customer Success Webinars
Tuesday, Mar 4, 4:00 PM UTC
Adobe Target innovations, including GenAI, and best practices on AI-powered personalization and experimentation at scale.
RegisterAdobe Target at Summit
Register for these developer sessions:
- Put the Customer at the Center and Build Relationships That Last a Lifetime (attend online)
- How T-Mobile Personalizes Customer Experiences with AI Decisioning
- A Tax Transformation: How H&R Block and Adobe MarTech Improved Engagement
- Do it Best Leverages the Adobe Platform to Drive Growth for Independents
- Had Me at First Click: Activate Your Audience with AI Content Discovery
Connect with Experience League at Summit!
Get front-row access to top sessions, hands-on activities, and networking—wherever you are!
Learn more