DIL-implementatie op de client

Als u deze methode gebruikt om Adobe Analytics-gegevens in AAM te krijgen, hebt u twee hits op uw webpagina's: Eén gaat naar Analyticsen één die naar AAM gaat (na het kopiëren van Analytics gegevens op de webpagina. Segments worden teruggestuurd van AAM naar de pagina, waar ze kunnen worden gebruikt voor personalisatie, enzovoort. Dit wordt beschouwd als een oudere implementatie en wordt niet meer aanbevolen.

Afgezien van het feit dat dit niet de beste praktijken volgt, omvatten de nadelen om deze methode te gebruiken:

  • Twee hits op de pagina in plaats van slechts één
  • server-kant het door:sturen wordt vereist voor het delen in real time van AAM publiek aan Analytics, zodat clientimplementaties deze functie (en mogelijk andere functies in de toekomst) niet toestaan

Men adviseert dat u zich aan een server-kant het door:sturen methode van AAM implementatie beweegt.

Server-kant het door:sturen implementatie

Zoals in bovenstaande afbeelding wordt getoond, komt een hit van de webpagina naar Adobe Analytics. Analytics die gegevens vervolgens doorsturen naar AAM in real time, en bezoekers worden geëvalueerd in AAM kenmerken en segments, net alsof de treffer rechtstreeks van de pagina afkomstig was.

Segments worden geretourneerd op dezelfde real-time hit als Analytics, die de reactie op de Web-pagina voor verpersoonlijking, etc. door:sturen.

Er is geen timing aan het bewegen naar server-kant door:sturen. Adobe raadt iedereen die zowel Audience Manager als Analytics gebruikt deze implementatiemethode.

U hebt twee hoofdtaken

Er staat nogal wat informatie op deze pagina, en dat is natuurlijk allemaal belangrijk. Zij alles komt neer op twee belangrijke dingen die u moet doen:

  1. Wijzig uw code van cliënt-kant DIL code in server-kant het door:sturen code
  2. Draai de schakelaar in Analytics Admin Console om de daadwerkelijke doorzending van gegevens te starten (per report suite)

Als u één van beiden van deze taken overslaat, server-kant door:sturen zal niet correct werken. Er zijn stappen en aanvullende gegevens toegevoegd aan dit document, zodat u deze twee stappen correct kunt uitvoeren.

Implementatieopties

Aangezien u zich van cliënt-kant aan server-kant het door:sturen beweegt, één van de taken u zult hebben verandert de code aan de nieuwe server-kant door:sturen code. Dit gebeurt op basis van een van de volgende opties:

  • Adobe Experience Platform-tags - Adobe aanbevolen implementatieoptie voor webeigenschappen U zult zien dat dit een gemakkelijke taak is, aangezien Platform-tags al het harde werk voor u hebben gedaan.
  • Op de pagina - U kunt de nieuwe SSF-code ook rechtstreeks in de doPlugins functie in uw appMeasurement.js bestand, als u (nog) geen Adobe Launch gebruikt
  • Andere tagmanagers - Deze kunnen op dezelfde manier worden behandeld als de vorige optie (Op de pagina), aangezien u de SSF-code nog steeds in doPlugins, waar de andere tagmanager de AppMeasurement code

Hieronder vindt u een overzicht van de De code bijwerken sectie.

Uitvoeringsstappen

In de volgende stappen wordt de implementatie beschreven.

Stap 0: Vereiste: Experience Cloud ID-service (ECID)

De belangrijkste voorwaarde voor de overgang naar server-kant door:sturen moet de Experience Cloud ID Service hebben uitgevoerd. Dit is het gemakkelijkst gedaan als u Experience Platform Launch gebruikt, in welk geval u eenvoudig de uitbreiding ECID installeert en het de rest zal doen.

Als u een niet-Adobe TMS of helemaal geen TMS gebruikt, moet u ECID implementeren om voor andere Adobe-oplossingen. Zie de ECID-documentatie voor meer informatie . De enige andere voorwaarde is betreffende codeversies, zodat aangezien u eenvoudig de meest recente versies van de code in de volgende stappen toepast, zult u in orde zijn.

NOTE
Lees dit gehele document voordat u het implementeert. De sectie "Timing" hieronder bevat belangrijke informatie over wanneer moet u elk onderdeel implementeren, inclusief ECID (als dit nog niet is geïmplementeerd).

Stap 1: Momenteel gebruikte opties uit DIL-code opnemen

Aangezien u bereid wordt om zich van cliënt-kant DIL code aan server-kant door:sturen, is de eerste stap alles te identificeren dat u met DIL code doet, met inbegrip van douanemontages en gegevens die naar AAM worden verzonden. U kunt onder andere de volgende dingen opmerken en overwegen:

  • Normaal Analytics variabelen, gebruiken siteCatalyst.init DIL module - U hoeft zich geen zorgen te maken over deze module, omdat het alleen gaat om het verzenden van de normale Analytics variabelen over, en dat gebeurt door eenvoudig te hebben server-zij toegelaten door:sturen.
  • Subdomein van partner - in DIL.create functie, noteer de partner parameter. Dit is gekend als uw "partner subdomain,"of soms "partner identiteitskaart,"en zal nodig zijn wanneer u de nieuwe server-kant het door:sturen code plaatst.
  • Visitor Service Namespace - Wordt ook wel ' 'Org ID" of "IMS Org ID," hebt u dit ook nodig wanneer u de nieuwe servercode voor doorsturen instelt. Noteer dit.
  • containerNSID, uuidCookie, en andere geavanceerde opties - maak een nota van om het even welke extra geavanceerde opties u gebruikt zodat u hen in de server-zij het door:sturen code kunt plaatsen eveneens.
  • Aanvullende paginabariabelen - Als andere variabelen van de pagina naar AAM worden verzonden (naast de normale Analytics variabelen die door siteCatalyst.init worden behandeld), zult u nota van hen moeten maken zodat zij binnen via server-zij het door:sturen kunnen worden verzonden (spoiler waakzaam: via contextData variabelen).