Expand my Community achievements bar.

Edge Data Collection Concepts: A4T

Avatar

Employee

4/3/25

If you’re planning to migrate Adobe Analytics and Adobe Target to Edge Data Collection, you may be wondering how this impacts your Analytics for Target (A4T) integration. A4T provides valuable insights into Target activities with Analytics data without duplicating data collection efforts between services. Preserving this integration is critical to maintaining accurate reporting during your Web SDK migration.

This blog covers key considerations of A4T with Web SDK, including the importance of migrating both libraries together, validation steps, expected reporting variances, and common pitfalls to avoid.

Migrate Libraries Together

With Web SDK, A4T stitching is handled automatically behind the scenes by Konductor, the orchestration layer in Edge Network. The big catch is that both systems (Analytics and Target) need to be running on Web SDK for A4T to function. This means AppMeasurement.js and at.js need to be migrated at the same time, at least on a page-by-page basis.

While legacy libraries need to be migrated together, you can migrate sections of your site incrementally. For example, you can migrate your home page to Edge Data Collection before migrating product pages from legacy libraries, but you cannot mix and match libraries on a page which can lead to disruption in A4T.

Ensure that your Web SDK datastream has both Analytics and Target enabled. With these services configured, Analytics calls will be augmented with the Target data, enabling A4T. For step-by-step instructions on implementing A4T, follow the A4T Implementation Guide.

Validation of A4T

To validate that the A4T integration is working in your Web SDK implementation be sure to check the following:  

  1. ECID and Correlation ID: Use AEP Assurance to verify that the Experience Cloud ID (ECID) and correlation ID are consistent between Analytics and Target calls. The ECID can be found in the payload response of the request under the ECID namespace, and the correlation ID can be found in the scopeDetails of your propositions in the decisioning.propositionDisplay event.  
  2. Web SDK Parameters: Validate that Analytics and Target events include the necessary A4T parameters, such as eventType: decisioning.propositionFetch.

Analytics Data Variances

Depending on your Target implementation, you may notice some variances in your Analytics data. These variances can generally be avoided if you’re using one top-of-page call for Analytics and Target. However, there are cases where your implementation might require Target to load on top-of-page and Analytics to load on bottom-of-page. If your Target call is using Guided Events, the eventType will be set as decisioning.propositionFetch and Analytics will ignore this as a page view or link click, but both server calls will be recorded which can lead to some variances in Analytics data such as:  

  • Spike in “unspecified” counts for eVars: Generally, eVars are not populated in the top-of-page call, causing eVar values to be “unspecified”. You may see an increase in “unspecified” values if you’re using metrics like Occurrences or Visits.  
  • Drop in bounce rate: The extra server call being made to Analytics will cause a drop in bounce rate.  
  • Spike in referrer instances: While AppMeasurement sets the referrer once per page load, Web SDK sends the referrer on every event. This can cause discrepancies in your Marketing Channels if your rules depend on tracking codes that don’t exist in your top-of-page calls.

For these reasons, it’s important to set the correct eventType and page view or link click parameters in your Target calls. Refer to this documentation to understand how Web SDK determines link clicks and page views.

Potential Pitfalls

Avoid these potential pitfalls during your migration to maintain A4T reporting: 

  1. Incomplete provisioning: If you are a new Adobe customer who has never used A4T before, you must be provisioned for it. 
  2. Mixing libraries on the same page: Using legacy libraries alongside Web SDK can disrupt A4T data stitching. 
  3. Incorrect event types: Ensure Target calls include appropriate eventType values to avoid unintended Analytics page views or link clicks.

Check out this blog from @chrismdavis and @kscally24 on other potential discrepancies with A4T reporting. 

Conclusion

Carefully planning your Analytics and Target migrations to Edge Data Collection will help to ensure a smooth transition and preserve your A4T functionality. With proper preparation you can continue to leverage the value of A4T for your personalization activities and gain insights from reporting.