If you want a user account, here's mine: I went through lots of rounds with paid support form Adobe on this very topic. Ultimately our internal trust of the metrics generated by the A4T integration (at the time it was very new and had data duplication errors) eroded and we abandoned the Target product. Now that they both use the Analytics data as source, I imagine much of our issues have since been resolved. But we did have a problem with general latency of the Target/A4T system taking too long and adversely impacting page performance. We are talking 5-7 second page load times. Granted, a lot of that was caused by our own site load times being high. But it was exacerbated by how long it took Adobe VisitorAPI services to do their part in the DOM. We could not deploy asynchronously with iQ because the latency introduced by the Adobe server calls and client-side redirects for our A/B strategy was impacting our conversion rates. We abslutely had to have the at.js file in the <head> to reduce latency. The Target processes which perform DOM overrides and redirects could not wait for Tealium's utag.js. Here's what I did: Parked both VisitorAPI.js and at.js in a publicly accessible server location. Deployed at.js through the sync.utag.js file in the <head>, so we could still manage the integrations without bothering dev teams. Modified the at.js library in the Target admin UI to include some code to look for a cookie confirming explicit consent. Since it's loading outside of the Tag ecosystem, it's not directly managed by Privacy Manager component. A little nod to GDPR here. Loaded the VisitorAPI.js file individually and synchronously in via the sync.utag.js method as well, just before the at.js call. Same tie-in to consent cookies. Loaded Adobe Analytics asynchronously, bundled into utag.js. It was set to run visitorAPI only if it wasn't already called. Sort of a fail-safe. That made the VisitorAPI run first, triggered even before utag.js but still managed by consent. It was all a ploy to reduce latency caused by the slow response times from the VisitorAPI service, saving us aobut .5 seconds vs bundling in utag.js. At one point I copy/pasted all of VisitorAPI.js and at.js into sync.utag.js to reduce remote server calls. It ended up quite messy and we even tried reverting to a pre A4T version to try to improve performance. We thought "if Target doesn't rely on VisitorAPI, then it can get to work sooner." But then data between Adobe products would be out of sync." That was the unresolvable crux of the problem. Ultimately, we dropped Target altogether and now use Optimizely. But the same issues may still present themselves. You have to decouple DOM overrides and redirects from measurement. With Optimizely's recommendation, and I am sure you can do it with Target, we now park all measurement events in an array if the dependencies are not initialized yet. Once all the depencencies are present, we push the array through the event handler to both the A/B system and the analytics systems. That reduced our data synchronization problem immensely. As for solving the page load latency caused by slow visitor API response times (relative to other platforms) -- that was only solved by using a different product with faster services. Optimizely also has a Full Stack product which we use to split in our server side code with no calls to remote servers (- bye bye latency -) though this is not a commercial. I know it's not much of a solution but it fits the bill of what you asked for: a user account of trying to work with this scenario. Cheers! Brett
... View more
Expand/CollapseMenu
