Adobe Target and Analytics in Launch and One network call- AEP SDK
Hi @MagicStar
assuming that Björn would be me xD
TL;DR; I would opt for a separation of Target and Analytics page views, see reasons below (and bullet points on how to integrate it), and this his how to do it
-------------
Long version
So, in general yes, you can put Target and Analytics data in a single call. That is what alloy / Web SDK has been designed for, forwarding data to the endpoints that have been configured in the datastream. You can add tool-specific context in the data section e.g., data.__adobe.analytics or data.__adobe.target that contains for instance through an XDM data variable.
Bear in mind though that a Target call must execute as early as possible to limit visual impacts / flicker, whereas a page view may be triggered at some later stage.
But - and this may be my personal opinion - you must decide whether you actually want to send Target and Analytics within the same call, especially from a consent perspective.
Yes, it sounds too good to be true, one library to rule them all, but the Adobe tools connected to the datastream may belong to traditionally different cookie consent categories, for instance "Analytics" for AppMeasurement/Adobe Analytics and "Personalization" for at.js/Target.
While in theory, AEP and Web SDK only requires the "collect" cookie consent category to work (which I typically tend to map to the classic Performance/Analytics cookie consent category), you could go crazy from that moment, since Adobe Target by itself does no longer write a cookie, and hence no additional cookie consent would be needed.
Call me old fashioned, but I like to interpret a cookie consent banner more like "which categories of tools would you, dear customer, allow me to use".
In other words, I respect the will of the visitor, and if my consent banner shows both analytics and personalization categories, for me that means that if he says no to personalization and yes to analytics, I must make sure Target activities are not triggered.
So, in other words, my go-to setup comprises
- one "library loaded" rule that
- requires Personalization consent
- triggers a Target cal, using guided events with "Request personalization" to make sure data is not inadvertedly sent to Analytics
- one "page view" rule that
- requires Analytics/Performance consent
- is typically event-driven and triggered by an event being pushed to my data layer
- uses guided events with "Collect analytics" to make sure no Target activity get rendered
Cheers from Switzerland!
Hi @MagicStar
using the guided events, I have not really experienced any issues so far.
Can you provide screenshots of your version that did not work?
Cheers from Switzerland!
Guided events as such should work, and I would recommend using them to keep the tools separate as described above.
When you are using SPAs, make sure to set the viewName (I typically give it the same value as the page name).
This will allow the visual experience composer to detect view changes (assuming you are sending a page view event with each)
Cheers from Switzerland!
thank you, going with 2 network calls, i totally am with you on consent and other benefits. Infact adobe doc recommends moving to split call as per the documentation that adobe support shared lately What Features Are Included in Previous Releases? | Adobe Target
, We need for multipage flow and with no a4t provisioned, we use adobe target reporting and AA reporting
Few questions prior to closing the loop on this
1. I heard folks say that guided events were mainly used for SPA and not multipage. Is it not for multipage - any pros cons you think?
2. Do you know of guided events and concerns with target or analytics reporting? I see below error while experience renders with guided events. This crops up in sdk logs within AA call when it has finished at the very end. I sense this is since a4t is not provisioned. Adobe support is looking into it as well
[0].cause.detail":"The 'com.adobe.target' service failed to return data for the 'target.adobe.com/analytics' shareable component.","c.a.e.[0].cause.errorcode":"205","c.a.e.[0].cause.namespace":"EXEG","c.a.e.[0].cause.statuscode":"502","c.a.e.[0].cause.title":"Data exchange producer request failed.","c.a.e.[0].id.name":"target.adobe.com/analytics","c.a.e.[0].id.tags.[0]":"reporting","c.a.e.[0].status":"failure",
3. Without guided events and top bottom events per documentation - non spa multipage app - https://experienceleague.adobe.com/en/docs/experience-platform/web-sdk/use-cases/top-bottom-page-eve... i see the below error in the log in AEP sdk, experience renders and reporting worked in adobe target and AA
"Service 'com.adobe.target' is not enabled on current event (conditions not met). "
4.Any benefits to upgrading AEP sdk from 2.27.0 to latest?
5. The order of calls i see is - First call has proposition fetch and then second call has page views that combines decisioning
Call 1 -
Call 2 -
6. What does doc mean by Luma triggers one network call when the site triggers two? https://experienceleague.adobe.com/en/docs/platform-learn/implement-web-sdk/applications-setup/setup... "The data layer on the Luma site is completely defined before the tags embed code. This allows us to use a single call to both fetch personalized content (e.g. from Adobe Target) and send analytics data (e.g. to Adobe Analytics). Doc needs update perhaps?
7. Would the second network call keep appending the propositions from previous page load even if the page you load has no targeted experience? This is seen in 2nd call on guided and non guided events.
eg. load page 1 with experience -
Now load another page with experience , it appends previous proposition and adds new.
Difference is only the proposition that has loaded the experience or the one that gets resolved shows below
[*]
Going to any other page without experience now shows both propositions without the traffic type etc [*]
What is shown if the experience does not come from the activity or if page is rendered with no activity is
8. Flicker - is the code(Async) from the sdk to be used or the one in document? I used below[1] from document on flicker and in works but [2] is what is in the doc
Difference between two is "".personalization-container { opacity: 0 !important }", 3000); " vs "body { opacity: 0 !important }", 3000);"
<script>
!function(e,a,n,t){var i=e.head;if(i){
if (a) return;
var o=e.createElement("style");
o.id="alloy-prehiding",o.innerText=n,i.appendChild(o),setTimeout(function(){o.parentNode&&o.parentNode.removeChild(o)},t)}}
(document, document.location.href.indexOf("adobe_authoring_enabled") !== -1, "body { opacity: 0 !important }", 3000);
</script>
[2]<script> !function(e,a,n,t){var i=e.head;if(i){ if (a) return; var o=e.createElement("style"); o.id="alloy-prehiding",o.innerText=n,i.appendChild(o),setTimeout(function(){o.parentNode&&o.parentNode.removeChild(o)},t)}} (document, document.location.href.indexOf("adobe_authoring_enabled") !== -1, ".personalization-container { opacity: 0 !important }", 3000); </script>
Thats a loooot of questions xD
1) Guided events is not only for SPAs. For SPA tracking you have to set the web.webpagedetails.viewname in your Analytics page view to signal Target that a view change has happened
2/3) General question: have you enabled Target on your datastream? Never seen those questions before tbh
4) in general, I would keep my libraries up to date. The extensions are heavily tested and upgrades should in general not lead to any problems (at least I have never had any)
5) propositionFetch is the Target global mbox that you trigger early, then followed by your page view
6) the first call is the page view event that includes specific decisionScopes (formerly mbox) information that Target is returning in the response to be rendered on the page
response:
The second call you see is the actual display event of that activity that gets rendered in the hero banner
7) cannot say for sure
😎 That website is almost two years old. Hence, I would always go with the one from the Web SDK extension.
Cheers from Switzerland!
Typically the changes should propagate to the CDN quickly, maybe there was an issue. Sometimes, when you're in a corporate network, your proxy may also have some kind of caching enabled.
Glad that it worked in the end
Cheers from Switzerland!
Related Conversations
