4 Essentiële methoden voor het samenvoegen van sessies in Google Analytics - DeLaatbusiness

4 Essentiële methoden voor het samenvoegen van sessies in Google Analytics

12 min


132
6 gratis internet marketing ebooks, klik hier voor download

Met één muisklik kan een gebruiker Google Analytics-gegevens vernietigen: het verplaatsen van een AMP-pagina naar de hoofdsite of de hoofdsite naar een betalingsverwerker kan een bezoek in meerdere sessies veranderen, waarbij de brongegevens onderweg worden gemolken.

Van cruciaal belang is dat deze klikken vaak plaatsvinden bij hoogwaardige overgangspunten-van anonieme bezoeker tot ingelogde gebruiker of van het moment van vóór de aankoop.

Sessie naaien herstelt technische breuklijnen, bewaart schone analytische gegevens en redt toekenningsinformatie. Dit bericht behandelt vier veel voorkomende gevallen:

  1. Gebruikers-ID tracking
  2. AMP-tracking
  3. Subdomein volgen
  4. Cross-domein tracking

Wat is sessie naaien?

In Google Analytics verbindt sessie naaien gebruikersactiviteiten die binnen een enkele sessie plaatsvinden, maar die vanwege technische beperkingen van het volgen van fouten niet meerdere sessies genereren.

Elke poging om een ​​sessie te maken, hangt af van twee elementen, die Simo Ahava beschrijft :

  • Een tracker-object dat naar dezelfde Google Analytics-property-ID (UA-XXXXXX-Y) traceert
  • Een _ga-cookie met dezelfde klant-ID

Moderne browsers staan ​​websites van het ene domein niet toe om cookies te delen met een ander domein. Het overwinnen van die beperking staat centraal bij het samenvoegen van sessies die anders uit elkaar gaan.

De term ‘sessie naaien’ wordt vaker gebruikt door digitale marketeers dan Google, die de laatste tijd de voorkeur heeft gegeven aan twee andere termen:

  1. Sessie eenwording . “Sessie-unificatie zorgt ervoor dat hits die zijn verzameld voordat de gebruikers-ID is toegewezen, worden gekoppeld aan een ID.”
  2. Site linken . “Cross-domein tracking maakt het voor Analytics mogelijk om dit als één sessie te zien door één gebruiker. Dit wordt ook wel sitekoppeling genoemd. “

Met name het ondersteuningsartikel van Google Analytics over sessie-unificatie behoudt de zinsnede “session stitching” in afbeelding alt-tekst en titels ( voor nieuwsgierigen ); een verdwaalde verwijzing naar sessie naaien wordt ook weergegeven in het ondersteuningsartikel voor de Google AMP Client ID API.

In dit artikel gebruik ik sessie naaien is een overkoepelende term die alle pogingen omvat om gebruikersactiviteiten die plaatsvinden binnen een enkele sessie correct te groeperen. Zoals Yehoshua Coren opmerkt , is de onderliggende technische realiteit belangrijker dan de terminologie: “Het is echt meer dan dat. Het is een clientId integriteitsprobleem. “

De uitdaging – hoe je het ook noemt – heeft invloed op de gegevenskwaliteit en de attributie voor bijna elke site.

Wie zou zich het meeste zorgen maken over sessie naaien?

Sessie naaien is handig voor elke site maar essentieel voor een paar:

  • Sites met logins. Sites met logins vertrouwen op ‘sessie-unificatie’ om gegevens te verzamelen over gebeurtenissen die leiden tot een gebruikersaanmelding.
  • AMP-zware sites. Goed bijhouden houdt toeschrijvinggegevens bij wanneer gebruikers migreren van een AMP-pagina naar een lokaal gehoste niet-AMP-pagina.
  • Grote organisaties met meerdere domeinen. Voor meerdere domeinen is het bijhouden van meerdere domeinen vereist om de toewijzingsinformatie te behouden wanneer gebruikers migreren over domeinen (of subdomeinen).
  • Sites met externe betalingsprocessors. Zonder sessie naaien kunnen sites die gebruikmaken van externe betalingsprocessors mogelijk toeschrijvingsgegevens verliezen voor e-commerce conversies.
  • Sites die sociale logins gebruiken. Net als externe betalingsprocessors kunnen sociale aanmeldingen gebruikers die zich na het inloggen aanmelden, onterecht herindelen als verwijzingen van het sociale netwerk.
  • Sites met iframe-formulieren. Iframes integreren een cross-domein tracking-uitdaging binnen een pagina op uw site.

1. Gebruikers-ID tracking

Voor sites met een inlogfunctie verbindt User ID-tracking meerdere bezoeken in de loop van de tijd, waardoor een bedrijf bijvoorbeeld kan zien welke SaaS-functies resoneren met klanten.

Sessie-unificatie voegt de pre-login-activiteit samen met de gebruikers-ID na aanmelding – waarmee een enkele sessie van de twee wordt gemaakt. Op die manier kunt u zien welk gedrag aan een log-in voorafgaat, iets wat vooral waardevol is als die login een conversiepunt vertegenwoordigt.

Dus in plaats van slechts een deel van de tweede sessie (eerste afbeelding) vast te leggen, voegt sessie-unificatie pre-login-hits (wit) samen met hits na aanmelding (blauw):

geen sessie-unificatie

met sessie-unificatie
Beeldbron )

Belangrijk is dat sessie-unificatie hits alleen koppelt als “deze hits plaatsvinden binnen dezelfde sessie waarin een specifieke ID-waarde voor de eerste keer wordt toegewezen.” Met andere woorden, het bevat gegevens van de sessie die voorafgaat aan de login-niet vorige sessies.

Google Analytics past sessie-unificatie toe tijdens de verwerking van dagelijkse analyses – “elke dag om 5 uur, op basis van de meest westelijke tijdzone die is geselecteerd in een rapportageweergave die aan de property is gekoppeld.”

Die vertraging kan leiden tot “hogere directe sessies en directe inkomsten tijdens intradaydatums omdat [. . .] Verwijzingsinformatie voor de campagne wordt verzonden tijdens de eerste treffer van een sessie waarbij de gebruiker zich nog niet heeft aangemeld. “

Standaard is sessie-unificatie schakelt op bij het instellen van User ID tracking. Waarom zou je het ooit willen uitschakelen? Ik vroeg aan Silver Ringvee, een van onze CXL- analisten. Hoewel hij geen voor de hand liggend geval zag, speculeerde hij op een mogelijke:

Er kunnen echter enkele gevallen zijn waarbij u zich echt wilt richten op de daadwerkelijk ingelogde gebruikers (en niet op gebruikers die zich op enig moment van de reis hebben aangemeld). Dus als je niet geeft om wat er gebeurde voordat ze de ID kregen, wil je het misschien uitschakelen.

U kunt sessie-unificatie uitschakelen in Beheerder> Eigenschap> Trackinginfo> Gebruikers-ID:

gebruikers-ID instelling in google analytics

Hoewel het bijhouden van gebruikers-ID’s het meest relevant is voor sites met verwachte logins (bijv. SaaS, e-commerce), zijn er andere manieren om aanmoedigen te stimuleren. Sites zoals Quora en Glassdoor plaatsen waardevolle content van hoge kwaliteit achter log-in walls, bijvoorbeeld.

Voor die inlogtypen levert sessie-unificatie belangrijke gegevens over de meest boeiende inhoud: de antwoorden of artikelen die logins en aanmeldingen katalyseren.

2. AMP-tracking

De AMP-implementatie van Google heeft trackingproblemen veroorzaakt: met AMP-klikken uit de zoekactie worden gebruikers naar de versie ‘AMP on cache’ gebracht, die wordt gehost op het CDN van Google.

Zoals Perficient’s Eric Enge me zei: “Veel mensen begrijpen dit nog steeds niet. De subtiliteiten van het volgen van kruisdomeinen (van de Google-cache tot uw daadwerkelijke domein) gaan verloren bij de meeste uitgevers. “

Uiteindelijk kunnen gebruikers op een van de drie manieren toegang krijgen tot AMP-pagina’s ; Elke impact heeft waar de klant-ID wordt opgeslagen:

  1. Google zoeken. AMP-pagina is toegankelijk via een Google-zoekresultaat en wordt weergegeven in een ‘AMP-viewer’. De klant-ID wordt opgeslagen op google.com.
  2. Proxy / Cache. AMP-pagina is toegankelijk via een proxy / cache. De client-ID wordt opgeslagen op cdn.ampproject.org.
  3. Directe AMP. AMP-pagina is rechtstreeks toegankelijk op het uitgeversdomein. De klant-ID wordt opgeslagen in het uitgeversdomein.

In de eerste twee gevallen genereert een klik naar een andere pagina op de site van de uitgever vanaf de AMP-pagina een verwijzing en een nieuwe sessie, in plaats van de klik als de tweede interactie in één sessie te tellen.

Amp tracking diagram
Stone Temple beschrijft de levering van informatie van een in-search AMP-klik naar een niet-AMP-pagina. ( Beeldbron )

Onbeheerd gelaten, hebben de resulterende analysegegevens verschillende problemen:

  • Opgeblazen sessie telt
  • Hoog weigeringspercentage op AMP-pagina’s
  • Lage pagina’s per sessie / sessieduur voor AMP-pagina’s

Net als bij andere problemen met sessie naaien, is de oplossing om dezelfde klant-ID door te geven tussen pagina’s op verschillende domeinen, die Google mogelijk maakt via de AMP Client ID API.

Hoe u de Google AMP API gebruikt om dezelfde klant-ID door te geven

Het instellen van AMP-tracking heeft twee stappen: wijzigingen in Analytics-code en uitsluitingen van verwijzingen.

client-ID delen van amp-tracking
Door de client-ID door te geven van de AMP-pagina naar het domein van de uitgever worden de brongegevens bewaard en worden gebruikersactiviteiten in één sessie gecombineerd. ( Beeldbron )

1. Wijzigingen in Analytics-code. Goede AMP-tracking begint met kleine toevoegingen aan de Google Analytics-code op AMP- en niet-AMP-pagina’s. Google biedt informatie  over het aanbrengen van wijzigingen voor analytics.js, gtag.js en Google Tag Manager.

Omdat sommige browsers cookies van derden weigeren, kondigde Google in september 2018 de AMP Linker aan, die URL’s versiert met klant-ID-informatie, waarbij de op cookies gebaseerde beperking wordt omzeild. AMP Linker vereist geen aanvullende instellingen als u de Google AMP Client ID-API al heeft ingeschakeld.

versterker decorator
Beeldbron )

2. Uitsluitingen van verwijzingen. Bovendien moet u ampproject.org als verwijzingsuitsluiting toevoegen. Als u AMP-inhoud uit meerdere subdomeinen aanbiedt, raadt Google aan om voor elk daarvan een verwijzingsuitsluiting toe te voegen.

referral exclusion list settings google analytics

Volgens Enge is de huidige oplossing niet perfect: “U kunt het verschil niet zien tussen uw eigen gehoste AMP-pagina’s versus door Google CDN gehoste pagina’s.”

Die beperking is van invloed op sites met “canonieke AMP-pagina’s” -AMP-pagina’s die worden gehost in het uitgeversdomein en die de standaard (canonieke) versie van de mobiele pagina zijn. Een oplossing die hetzelfde artikel biedt, is het maken van een aangepaste dimensie op Hitniveau.

Na de eerste installatie zijn de wijzigingen van invloed op de Google Analytics-gegevens voor de korte termijn :

  • Totale gebruikers en sessies zullen afnemen. Bij het samenvoegen van AMP- en niet-AMP-sessies worden verkeerd gescheiden gebruikers en sessies gecombineerd.
  • Gerelateerde statistieken zullen nauwkeuriger worden. Het bouncepercentage op AMP-pagina’s daalt bijvoorbeeld.
  • Nieuwe gebruikers zullen stijgen. De Google AMP API maakt een eenmalige reset van de client-ID voor AMP-bezoekers. Zoals Google opmerkt : “Afhankelijk van de frequentie waarmee gebruikers uw site (s) bezoeken, kan dit een opvallende, tijdelijke fluctuatie in uw statistiek en gerelateerde rapportage voor nieuwe gebruikers veroorzaken.”

3. Subdomein volgen

Het volgen van subdomeinen is aanzienlijk eenvoudiger geworden en is afhankelijk van een instelling voor het cookiedomein. Eerder was een handmatige stap, het instellen van het cookiedomein (cookieDomain) op ‘automatisch’, nu de standaardoptie in Google Analytics-scripts en de Google Analytics-instellingenvariabele in Google Tag Manager.

Simo Ahava legt uit dat het instellen van het Cookie Domain op “auto” een recursief algoritme toepast

probeert de cookie te schrijven, te beginnen met het meest algemene domeinniveau (het hoofddomein) en te stoppen zodra het lukt. Wat overblijft is het hoofddomein en dus is de cookie beschikbaar voor alle subdomeinen.

Omdat het algoritme de cookie op het hoogst mogelijke niveau instelt (het hoofddomein), genereert een gebruiker die op een subdomein landt en later naar het hoofddomein migreert, geen nieuwe klant-ID – of start een nieuwe sessie.

Een tweede stap is om uw hoofddomein toe te voegen aan de lijst met verwijzingsuitsluitingen,  zodat bezoeken tussen subdomeinen en het hoofddomein geen nieuwe sessies initiëren. (De eerste stap zorgt ervoor dat Google de bezoeker ziet als dezelfde gebruiker. ) Google voegt het hoofddomein automatisch toe aan de lijst met verwijzingsuitsluitingen wanneer u uw Google Analytics-property maakt, maar de instelling is de moeite waard om dubbel te controleren.

In theorie automatiseren deze updates het bijhouden van subdomeinen – de lijsten met cookiedomeinen en verwijzingsuitsluitingen zijn standaard ingesteld op de juiste waarden.

4. Cross-domein tracking

Cross-domain tracking is het meest complexe van elk sessie-naaistelproces omdat veel oplossingen op maat zijn: juiste implementatie is afhankelijk van de instelling van uw site, betalingsverwerker, inlogtool of-Lord help you iframe.

Als meerdere sites dezelfde trackingcode delen maar er geen andere technische wijzigingen worden aangebracht:

  1. Analytics dupliceert sessies tussen domeinen (aangezien de client-ID niet van de ene naar de andere wordt overgedragen).
  2. De oorspronkelijke toeschrijvinginformatie gaat verloren, omgezet in een verwijzing van het andere domein, die, omdat deze dezelfde trackingcode deelt, als een zelfverwijzing wordt weergegeven.

Net als bij AMP-tracking is voor succesvolle cross-domein tracking vereist dat de client-ID van de ene site naar de andere wordt doorgegeven zonder de cookie zelf door te geven. Er zijn verschillende belangrijke use-cases, elk met unieke oplossingen.

Interne cross-domein tracking

cross-domein trackingdiagram
Beeldbron )

Grote organisaties beheren vaak verschillende domeinen, maar willen bezoekers volgen terwijl ze van de ene naar de andere gaan. Ervan uitgaande dat de sites dezelfde Google Analytics-code delen, heeft het bijhouden van gebruikers over meerdere domeinen drie extra stappen.

De eerste twee stappen wijzigen de trackingcode om domeinen toe te staan ​​om client-ID’s door te geven en te ontvangen via links:

  • Auto Link Domains. Voeg alle domeinen toe als een door komma’s gescheiden lijst met de Google Analytics-instellingenvariabele in Google Tag Manager of pas uw Google Analytics-code aan met die domeinen.

autolink-domeinen screenshot

  • allowLinker. Om ervoor te zorgen dat domeinen Client-id’s kunnen ontvangen die via links worden doorgegeven, voegt u een veld toe in de Google Analytics-instellingenvariabele in Google Tag Manager met de naam “allowLinker” en stelt u de waarde in op “true”. (Als de gebruikersstroom één richting is, moet u laat de linker alleen toe op doel-niet brondomeinen.)

allowlinker screenshot

De linker voegt een tijdstempel en andere metagegevens toe om de client-ID te valideren, waardoor de kans kleiner is dat een gedeelde link met de klant-ID invloed heeft op Analytics-gegevens.

De laatste stap is om alle domeinen toe te voegen aan uw lijst met uitsluitingen van verwijzingen. Anders genereert u bergen met zelfverwijzingen – Google Analytics herkent een gebruiker tussen domeinen, maar genereert nog steeds een nieuwe sessie.

Als u gegevens wilt analyseren die zijn verzameld door efficiënt cross-domein volgen, plaatst u de hostnaam voor het URL-pad. Anders worden paden die door meerdere domeinen worden gedeeld, gegroepeerd. Beide onderstaande URL’s worden alleen weergegeven als / over-us / in rapporten op paginaniveau:

https://example.com/about-us/

https://another-example.com/about-us/

U kunt de hostnaam vooraf plaatsen door een aangepast filter in te stellen met de volgende waarden:

aangepast filter om de domeinnaam te tonen

(Als u historische gegevens probeert te redden die niet correct zijn gefilterd, kunt u een secundaire dimensie met de hostnaam gebruiken om URL’s te onderscheiden in een weergave.)

Verwerking door derden

Voor de verwerking van betalingen door derden is een juiste configuratie van vitaal belang: zonder deze verliest u toeschrijvingsgegevens voor alle transacties, die worden weergegeven als verwijzingen van de betalingsverwerker. U hebt echter beperkte controle over de pagina van de betalingsprocessor.

Een oplossing is om een ​​verwijzingsuitsluiting op te zetten voor het domein van uw betalingsverwerker ; maar die inspanning – een handmatige – zou een hele klus worden als:

  • Je werkt met veel betalingsprocessors.
  • Betalingsverwerkers veranderen vaak van domein.
  • Het uitsluiten van het domein van een proccesor riskeert ook het uitsluiten van “echt” verwijzingsverkeer (bijv. U krijgt verwijzingsbezoeken via een link op het blog van PayPal).
betaling door derden
Het uitgebreide antwoord? Sluit alle verwijzingen naar uw ontvangstpagina uit. ( Beeldbron )

Ahava beschrijft een creatieve, alomvattende oplossing: het creëren van een verwijzingsuitsluiting voor al het verkeer naar uw kwitantie of “dank u” -pagina. De verwijzingsuitsluiting behoudt de originele brongegevens en voorkomt dat Google Analytics een nieuwe sessie genereert wanneer gebruikers terugkeren naar uw site vanuit het domein van de betalingsprocessor.

De implementatie van Ahava’s oplossing kent twee stappen:

  1. Creëren van een aangepaste JavaScript-variabele. Stel een verwijzende waarde in van “null” voor de URL van uw bedankpagina .
  2. Aanpassing van de tags die op de bedankpagina worden geactiveerd. Voor elke tag die op uw bedankpagina wordt geactiveerd, stelt u het veld “verwijzer” in op de recent gemaakte variabele.

Een algemeen verbod op verwijzingen naar een bepaalde pagina kan riskant lijken, maar bedankt dat pagina’s alleen toegankelijk zijn (of toegankelijk moeten zijn) in de kassaticket-niemand begint zijn gebruikersreis op de bedankpagina, dus er is geen risico op verlies van waardevolle data bron.

Sociale logins

sociale inlogpagina

Sociale logins kunnen niet rekenen op een algemeen domein Verwijzingsuitsluiting – hoewel een Google-login mogelijk afkomstig is van accounts.google.com (een subdomein dat u veilig kunt uitsluiten), anderen, zoals Facebook, komen via facebook.com en bijna elke site heeft niet-inlog-verwijzingsverkeer van Facebook.

Een veelvoorkomende oplossing is om de autorisatie te openen in een nieuw tabblad of venster, dat de continuïteit in de sessie op uw site onderhoudt. Ad-blockers kunnen dit proces echter belemmeren, of u kunt – omwille van de gebruikerservaring – liever geen nieuw venster openen.

Een andere oplossing – net als de strategie van Ahava voor bedankt pagina’s – is om verwijzende informatie voor de inlogpagina die op uw site wordt gehost, te negeren of te negeren . Door de verwijzende waarde in te stellen op uw eigen domein of “null”, zorgt u ervoor dat de bron registreert als Direct, waardoor de enkele sessie behouden blijft. De strategie werkt alleen als de pagina na inloggen een unieke URL heeft.

iframes

Iframes vormen een uitdaging voor sessie naaien, gedeeltelijk omdat iframe-inhoud meestal wordt geladen voordat Analytics-tags worden geactiveerd. Dat betekent dat traditionele tracking-oplossingen, zoals het toevoegen van de client-ID aan de URL, aanpassing vereisen, zoals de ontwikkelaarshandleiding van Google:

Om dit probleem op te lossen, kunt u de pagina in het iframe zo configureren dat het vertragen van het maken van de tracker wordt uitgesteld tot nadat de client-ID-gegevens van de bovenliggende pagina zijn ontvangen. En op de bovenliggende pagina configureert u deze om met behulp van postMessage de client-ID naar de iframe-pagina te verzenden.

Pijnlijk als cross-domein tracking op iframes kan zijn – Ahava verwijst naar hen als “niet traceerbare kleine shit-monsters die bestaan ​​in de leegte tussen websites” -ze worden (te) vaak gebruikt in webformulieren door verkopers die zich meer richten op het verplaatsen van vorm gegevens in een CRM dan dat deze interacties traceerbaar zijn in Google Analytics.

Bounteous legt het proces uit voor het gebruik van postMessage in cross-domein iframe-tracking:

we kunnen het iframe van ons kind een bericht laten uitzenden, dat we kunnen ‘beluisteren’ en gebruiken om GTM te informeren dat er een belangrijke interactie is opgetreden. Dit is geweldig voor het bijhouden van dingen zoals eenvoudige formulierinzendingen binnen iframes [. . .] We moeten de volgende stappen uitvoeren:

1.) Plaats een bericht van ons child iframe 
2.) Luister naar het bericht in ons bovenliggende frame 
3.) Wanneer we het bericht opvangen, druk dan een evenement in de GTM-gegevenslaag

Er is een belangrijk voorbehoud: je moet code aan het iframe kunnen toevoegen. Zo niet, dan zal het proces niet werken.

Ahava is auteur van twee oplossingen voor cross-domein iframe-tracking, waarvan de laatste customTask gebruikt :

De customTask-API is een functie van de Universal Analytics-bibliotheek (ook gebruikt door tags van Google Tag Manager). Hiermee kunt u waarden ophalen en instellen van en naar de (Measurement Protocol) -hit terwijl deze wordt gegenereerd.

Voor cross-domein iframe-tracking gebruikt “customTask een setInterval () -script dat periodiek de pagina opvraagt ​​tot het doel-iframe is gevonden of een time-out is bereikt.”

iframe trackingcode
De parameters voor het iframeDecorator-object in de oplossing van Ahava. ( Beeldbron )

Wanneer Google Analytics een treffer naar de bovenliggende pagina registreert, vraagt ​​de oplossing van Ahava customTask om te zoeken naar een iframe dat overeenkomt met een vooraf ingestelde CSS-selector en vervolgens de iframe-URL te versieren met de client-ID van de eerste treffer.

Zelfs die oplossing is echter fragiel, vooral als het iframe omleidingen bevat – “niet-traceerbare shit-monsters” inderdaad.

Conclusie

Sessie naaien lijnt Google Analytics-gegevens in met wat we weten waar te zijn: Gebruikers, navigeren in één keer, tussen domeinen, voltooien aankopen of vullen formulieren in die hen kortstondig van en naar een ander domein overbrengen.

De kritische aard van die interacties -voor- en na-aanmelding, anonieme bezoeker versus bekende lead, en potentiële klant versus verleden-inkoper-maken sessie-naaien zijn de moeite waard.

Het samenweven van gebruikersinteracties verbetert de toeschrijvingsgegevens en vermindert blinde vlekken op kritieke punten in de gebruikersreis.


What's Your Reaction?

hate hate
0
hate
confused confused
0
confused
fail fail
0
fail
fun fun
0
fun
geeky geeky
0
geeky
love love
0
love
lol lol
0
lol
omg omg
0
omg
win win
0
win
Erwin@delaatbusiness.com
Dag, Hulp nodig met internet marketing of websites maken? neem dan contact op

0 Comments

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Choose A Format
Personality quiz
Series of questions that intends to reveal something about the personality
Trivia quiz
Series of questions with right and wrong answers that intends to check knowledge
Poll
Voting to make decisions or determine opinions
Story
Formatted Text with Embeds and Visuals
List
The Classic Internet Listicles
Countdown
The Classic Internet Countdowns
Open List
Submit your own item and vote up for the best submission
Ranked List
Upvote or downvote to decide the best list item
Meme
Upload your own images to make custom memes
Video
Youtube, Vimeo or Vine Embeds
Audio
Soundcloud or Mixcloud Embeds
Image
Photo or GIF
Gif
GIF format