- TLC Home Home
- Discussions Discussions
- Documentation Documentation
- Knowledge Base Knowledge Base
- Education Education
- Blog Blog
- Support Desk Support Desk
12-11-2017 03:18 AM
Solved! Go to Solution.
12-11-2017 06:37 PM
12-11-2017 06:52 PM
12-12-2017 12:50 AM
Hi @zhaque,
I haven't solved it yet, but was wondering if it shouldn't just work as is.
I have been looking at this document:
https://marketing.adobe.com/resources/help/en_US/target/target.pdf
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!
Best regards,
Peter
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,
Adrian
12-13-2017 05:09 AM
Hi @adrian_browning,
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 ;-)
Best regards
Peter
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
<body> tag
- 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?
Cheers,
Björn
12-13-2017 08:28 AM
12-13-2017 11:02 PM
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:
utag.sync.js
- 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)
- Analytics
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.
Adrian
12-14-2017 05:39 AM
12-14-2017 06:06 AM
HI @bjoern_koth
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.
Adrian
12-14-2017 06:30 AM
Hi @adrian_browning,
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?
Best regards,
Peter
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?
Cheers
12-14-2017 07:37 AM
Hi both,
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 :-)
Best regards,
Peter
12-15-2017 07:56 AM
12-15-2017 08:03 AM
@adrian_browning and @dan_george
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.
Adrian
12-15-2017 09:29 AM
I will try to endeavour to update this thread when the update has been released for the beta tag.
This new Beta version has better handling when used in conjunction with load rules. Though with the current version a timing was found with regards to the logic that checks the load rule conditions. This update is again in the updated beta.
Adrian
12-15-2017 09:34 AM
Hi @pmeyerdk
With regards to the flicker, you are seeing I will reach out to @nathan_fleming and see if I can lend any assistance.
Adrian
12-16-2017 11:20 AM - edited 12-16-2017 11:21 AM
Many Kudos for this Target Beta Tag. Support help me enabled it for my account. Here are my feedback :
1. Happy to see that you can actually pass Target Page Params :) question variables passed are encoded e.g. "," is "%2C"
2. I am missing Target Enterprise Workspace support - It's a must for us to move to the tag as we have multi-department target install. I try to pass it as "custom dimension" but didn't do the magic - will it be added before the final release? - SOLVED PASSING IT As Target Page Params .. still needs actual validation.
2. I have found one JavaScript error so far.
Uncaught TypeError: window.__TEALIUM.adobe.target.css.removeRender is not a function at Object.u.showAllDivs (utag.js:136) at utag.js:147
4. Haven't seen any flicker issue yet - but need to run some A/A test before I can confirm.
More to come but very happy so far!
12-18-2017 01:32 AM
Good morning @zhaque
Adrian
12-19-2017 01:14 AM
Hi @adrian_browning,
Kevin Faurholdt have dound the cause of the error, and writes to me, that he will get the fix in the upcoming version of the tag.
He also "hardcoded" the change into the tag, in the profile I am testing it in.
Best regards,
Peter
Copyright All Rights Reserved © 2008-2023