Expand/CollapseMenu
01-02-2018 03:38 AM
pmeyerdk
Hi @adrian_browning,
I just tested the following, on an iQ profile with the new Adobe Target approach setup, using both tag and extension.
Shouldn't at least step two remove the code from utag.sync.js?
I am testing in DEV only, but the site I am testing on, is then also hardcoded to use DEV.
Could that be a problem in this regards?
Generally, I was trying to test, that if I disabled as mentioned above, that the code would be removed from utag.sync.js as well, so I was certain it was completely gone from the setup.
Sorry to be double-spammy, but I also wrote Customer Support to ask about this.
Best regards,
Peter
01-02-2018 03:46 AM
pmeyerdk
Ah... Sorry, now I know what's wrong ; -)
Because I had some trouble with the code added by the extension it self, your colleague Kevin Faurholt fixed it for me, but did this directly in the template.
Afterwards he of course forwarded information about this, to the persons working on the "real" tag and extension.
Sorry to bother you with this.
I will take this in account, and test properly ;-)
Best regards,
Peter
04-19-2018 12:26 AM
pmeyerdk
The solution to this, was actually to NOT implement Adobe Target directly on site, and Adobe Analytics and Visitor API through Tealium iQ.
This would bring a lot of work, and has been dropped because of that.
But using the "not yet launched" Adobe Target implementation method, which works really well.
So we're looking forward to getting that approach approved and launched for normal use.
Best regards
Peter
04-19-2018 10:40 AM - edited 04-19-2018 10:40 AM
Thank you for coming back and sharing @pmeyerdk!
04-23-2018 02:40 PM
BretCamble2
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:
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
04-23-2018 04:07 PM
Great stuff @BretCamble2. Thank you for sharing. Anybody else want to share as well? We love hearing from you!
04-24-2018 01:38 AM
pmeyerdk
Hi @BretCamble2,
Thank you very much for that explanation of your experiences!
That was exactly what I was hoping to get from this post.
As you might already have read here, our solution ended up being using the "beta non-public" Target approach in Tealium iQ.
This consists of one extension and one tag, and then the tag order Visitor API - Target - Analytics.
We tried this out, because it seemed to cumbersome to do all, or some, of it manually from outside Tealium iQ.
And your experiences tell me, that we took the right decision.
For us this is running nicely, and since it's also using Adobe Target new asynchronous way of working, it isn't stalling stuff, as we were very worried about, when looking at the old-school syncronous approach.
Once again, thank you for sharing!
Best regards
Peter Meyer
Copyright All Rights Reserved © 2008-2023
