12-11-2017 03:18 AM
12-11-2017 06:37 PM
I would be very keen to hear how you resolved it.
So the ID services will fire twice? Will it be a issue? I will give it a try in my testing enviornment - see what happens :)
12-11-2017 06:52 PM
Unfortunately when I try to paste VisitorAPI.js in Target UI (edit at.js template under setup/implementation) Target complains...
ERROR Library Header cannot be more than 10kb.
Keen to hear how you solve it..
12-12-2017 12:50 AM
I haven't solved it yet, but was wondering if it shouldn't just work as is.
I have been looking at this document:
On page 69 it mentions:
On to me, it seems like the Adobe Target process flow handles visitor identification.
I will have to test further, since I haven't tested this thoroughly.
But fellow community members, please share your input and experiences :-)
It isn't very easy to find the information, so any feedback would be much appreciated!
12-12-2017 08:54 AM
Hey @adrian_browning is this something you can speak to with all your Adobe Target knowledge you've accumlated over the last year?
12-12-2017 02:07 PM
From the exposure, I have had working on the latest Beta release of Target tag, and working with Adobe consultants. I would be surprised if you could get this scenario working smoothly. As the picture and document shows, the Visitor API needs to run first, before the Target code. This you will see, will send out a DMDEX request. This will then return and for both Target and Analytics, you will get a visitor ID to use. On the Target request, you will see the mid parameter, this is the visitor ID returned by DMDEX.
You might be able to call the Visitor service after manually call Target track method. This might be enough to stitch the mid to the request. Would have to test this though.
With the latest release of the Adobe Marketing Cloud ID Service and Adobe Analytics they have a communication method built into them, so if the Analytics tag is loaded second, after the Adobe Marketing Cloud ID Service tag, it will wait until it has returned before firing.
Hope this helps,
12-13-2017 05:09 AM
Thanks! I guess I have been miss-reading the flow illustration :-/
I actually had a very thorough talk, a couple of hours, with Kevin Faurholt about the upcoming new Target tag.
And your name was mentioned often in that conversation ;-)
I want to go for the new approach, but the label "beta", is holding that back a bit, in regards to which tags and extensions I will be allowed to use.
A bigger issue is, that we are a bit afraid of the utag.sync.js file being synchronous, as it should, since that makes us more vulnerable to non-answering scripts, blocking other stuff from loading and/or displaying.
So what we best do about that, we will have to find the solution for.
This I of course also discussed with Kevin.
It is now clearer to me, that if we don't use the new approach, I would have big work ahead, if I want to do something regarding the Visitor ID myself.
This part would be nice, to not have to do myself ;-)
12-13-2017 07:45 AM
This is actually quite interesting for us as well. We have the following setup:
utag.sync.js, loaded synchrounously in the <head>
- define Marketing Cloud Visitor ID Service and initialize it with our tracking servers (copied+pasted the whole library in the file)
- load the mbox.js via <script> tag to prevent flickering
- load Adobe Analytics tag
But the Marketing Cloud Visitor Service bloats the utag.sync.js file quite a bit and due to the 5 minute cached lifetime of the utag.sync.js this adds some extra request payload for returning visitors (after the cache timeout has expired).
What I don't get yet is why there is a tag for the Marketing Cloud ID Service if it required to load synchronously before Target, Audience Manager, Analytics, etc.
Is this somehot not a standalone tag in the classic way and instead rendered directly into the utag.js?
And if used, if see this correctly that will only work with the asynchronous version of Target, correct?
12-13-2017 08:28 AM
12-14-2017 04:01 AM
We have done something different for the 3 main Adobe tags, we have allowed them to effectively talk to each other.
So what happens is the following:
- Loads the hiding code required for Target
utag.js (Tags need to be in this order)
- Marketing Cloud (Will automatically bundle, and turn wait off)
- Target (Will automatically bundle, and turn wait off)
When Marketing Cloud loads it creates a lightweight publish/subscribe method. When the other 2 tags load/run they hook onto this so that they will carry out their main work once the visitor service has returned.
If the Marketing Cloud tag is not present, then Target/Analytics both have a stubbed version of this, and will execute immediately.
This methodology only works currently on the Beta Target tag which is indeed async. The 2 in the tag marketplace don't have this logic in place, as these will be deprecated once the beta version is fully released.
12-14-2017 05:39 AM
12-14-2017 06:06 AM
So the utag.sync.js file is populated by the Target extension, with code that hides the body and the defined mboxes.
This bit of code, adds a style tag to the dom with the hiding CSS.
The beauty of having just this in the sync file and then the rest loaded async is that there is no flicker.
You are correct this means the tag template gets added to the utag.js file, so there is no additional step of requesting the file from the CDN. By default, utag.js should only be loaded async. With this setup, we are hiding the body ASAP with the sync file, then allowing the Marketing Cloud / Target tags to fire as soon as they are able to.
Thanks to the Beta users we have found some items that needed to be fixed, in scenarios we hadn't thought of. These have now been addressed, and we are waiting for QA to complete their testing. I would imagine the updated beta to be released in Jan, with the full release happening a couple of weeks after, as long as no additional issues are identified.
12-14-2017 06:30 AM
But if I then delete the extension and/or the Adobe Target tag, will the code in utag.sync.js also be removed automatically, together with the code I guess will be removed from utag.js?
And if I only disable the extension and/or the Adobe Target tag, can I then be sure, that none of the code added together with the tag and extension will run?
12-14-2017 07:09 AM
12-14-2017 07:18 AM
one thing that came to my mind: if the Target tag is dynamically modifying the utag.sync.js file with necessary CSS changes, will it still be possible to control the tag through load rules?
Use case: we have certain pages that shall not fire Target. Will Tealium then serve a different looking utag.sync.js for them or will the CSS code always be there, yet not active on these pages?
12-14-2017 07:37 AM
I setup this new Adobe Target approach on one of our test sites, which I won't share the URL of here.
It seems to runs as supposed to, except one thing:
On the one page I added a test, I am experiencing flicker.
More precisely, I can see the original content switch to the changes made using a Target A/B test.
I might have done something incorrectly, and have an open support case with Nathan Fleming regarding this.
Just so you, @adrian_browning, at least know it :-)
12-15-2017 08:03 AM
12-15-2017 09:25 AM
So if you delete the extension, then no code will be added into the utag.sync.js file.
In the beta update going through QA this will also now set Adobe target to non-body hiding mode.
If you remove the tag, then nothing with regards to Target will get published out.
If you disable either/or then it will be like they weren't there.