De valkuilen bij het opzetten van e-commerce in Google Analytics

internet marketing

Ondanks gedetailleerde documentatie van Google, wordt het opzetten van geavanceerde e-commerce in Google Analytics vaak geassocieerd met ongedocumenteerde nuances. In dit artikel zullen we de moeilijkheden analyseren die we het vaakst tegenkomen in het bureau en opties bieden om de problemen op te lossen.

Situatie 1: verschillende niveaus van productparameterisatie in verschillende stadia van de trechter

De online winkel heeft configureerbare producten, dat wil zeggen producten die worden gedetailleerd tijdens het bestelproces. Om de waarneming te vergemakkelijken, zullen we het algemene product het woord “product” noemen, en de meest specifieke eenheid – “productaanbod”.

De gebruiker ziet bijvoorbeeld in eerste instantie rode schoenen van een bepaald model in de catalogus op de site – dit is een product. Op de productpagina kan de gebruiker de maat selecteren: 23, 24, 25, 26. Schoenen van elke maat zijn verschillende productaanbiedingen. In deze situatie kunnen product-id en productaanbieding-id niet hetzelfde zijn (en hun namen zijn waarschijnlijk ook verschillend).

We weten dat u met uitgebreide e-commerce gegevens kunt ontvangen in verschillende stadia van interactie met het product, ook al tijdens het bekijken van het product in de lijst.

Met andere woorden, de kenmerken van het product moeten hetzelfde blijven tijdens het hele proces van de klant door de trechter, van het bekijken van het product tot de aankoop.

Oplossingsmogelijkheden

Helaas is er geen perfecte oplossing voor dit probleem en moet u een compromis vinden of op zijn minst het minste kwaad. We geven toe dat de data in GA niet 100% de werkelijkheid weergeven, en passen hier mentaal op bij.

Eerste optie

De eenvoudigste, maar minst correcte manier is om alleen gegevens over het product over te dragen en te weigeren de gegevens van het productaanbod over te dragen.

Het voordeel van deze optie is dat het het leven van ontwikkelaars gemakkelijker maakt. Het heeft geen andere voordelen, dus als de tweede optie onmogelijk of erg moeilijk te implementeren is, dan is de eerste beter dan niets.

Aan de andere kant heeft het een nadeel: het werkt niet als u dynamische remarketing wilt gebruiken. De kenmerken van de producten in de feed en in de e-commerce moeten overeenkomen, wat betekent dat je feeds moet bouwen met de product-ID, niet met het productaanbod. Google raadt dit af: “Stel niet dezelfde ID in voor verschillende varianten van hetzelfde product.” Als u deze aanbeveling niet opvolgt, kan Google de feed helemaal afwijzen en de feed-gebaseerde advertenties niet meer beschikbaar maken voor uw winkel.

Tweede optie

In alle stadia waarin een specifiek productaanbod onbekend is, maar alleen het product bekend is (bijvoorbeeld de schoenmaat is onbekend en er wordt uitgegaan van verschillende opties), verzendt u standaard gegevens over de actie met een bepaald product.

We hebben bijvoorbeeld rode schoenen in maat 23, 24, 25, 26, laat de standaard maat 23 schoenen zijn. Wanneer we vervolgens een product in de lijst bekijken, op een product klikken en een productkaart bekijken, verzenden we de gegevens alsof deze acties worden uitgevoerd met schoenen van maat 23. Zodra de gebruiker een andere maat kiest dan de standaard maat op de productkaart, bijvoorbeeld maat 24, sturen we informatie over het bekijken van de kaart met de nieuwe huidige maat.

Alle volgende acties (toevoegen aan winkelwagen, afrekenen, kopen) worden uitgevoerd met een specifiek product. En dat geldt natuurlijk voor elke parameter.

Voordelen van de tweede optie:

elk fysiek exemplaar van het product wordt afzonderlijk weergegeven in de rapporten in Google Analytics;

geen probleem met dynamische remarketing.

Nadelen van de tweede optie

Het is duidelijk dat u in dit geval een aantal producten heeft die, volgens Google Analytics-rapporten, het vaakst in de lijst worden weergegeven en waarop het vaakst zal worden geklikt – dit zijn de standaardproducten. Tegelijkertijd zullen sommige producten (opnieuw volgens rapporten) niet in de lijst worden weergegeven, er zal niet op worden geklikt en toch worden ze aan de winkelwagen toegevoegd en gekocht. U kunt uit deze situatie komen door de volgende aanbeveling toe te passen.

Voor fysiek verschillende goederen van hetzelfde type, gebruik dezelfde naam, laat de naam bijvoorbeeld “Shoes red_model_1” zijn, hetzelfde voor schoenen van 23, 24, 25, 26, enz. In maat. Laat ze tegelijkertijd verschillende ID’s hebben en laat de maat worden weergegeven in het variantveld, als er meer dan één kenmerk is (bijvoorbeeld maat en kleur), kunt u ze overbrengen in aangepaste indicatoren op productniveau.

Derde optie

Stuur actiegegevens met alle productaanbiedingen van één product tegelijk. We raden af ​​om deze optie standaard te gebruiken, maar in sommige gevallen kan dit worden overwogen. Als er bijvoorbeeld op één productkaart vijf verschillende productvarianten tegelijk staan ​​en deze tegelijkertijd worden weergegeven. Dan is het logisch om aan te nemen dat de gebruiker de kaarten van vijf producten tegelijk bekijkt.

Situatie 2: overschrijding van de maximale aanvraaggrootte van Analytics

De maximale verzoekgrootte in Google Analytics is 8 KB, en hoewel dit veel is, wordt het vaak bij het overzetten van gegevens over productweergaven in de lijst overschreden en komen de gegevens niet in Analytics terecht.

Besluit

We raden aan om het script voor het overzetten van gegevens over productweergave in de lijst op te splitsen in verschillende scripts, die elk niet meer dan acht producten bevatten. Dit is een goede marge, in de meeste gevallen zou het voldoende moeten zijn. Als u echter veel aangepaste parameters doorgeeft, moet dit aantal nog verder worden verlaagd.

Situatie 3: gegevens overdragen net voor de omleiding

Productklikgegevens hebben niet altijd tijd om naar Analytics te gaan, omdat er te weinig tijd verstrijkt tussen de productklik en het laden van de productkaart.

In onze ervaring kan er 200-1000 ms verstrijken tussen de uitvoering van de gecontroleerde actie en de overdracht van gegevens naar het analysesysteem, afhankelijk van de snelheid van de site en de internetsnelheid van de gebruiker. In elk geval kan de tijd verschillen, dus we raden aan om deze experimenteel te controleren.

De gebruiker klikt op het product, waarna de klikgegevens onmiddellijk moeten worden verzonden en vervolgens moet de productkaartpagina worden geladen. Standaard wordt de pagina echter waarschijnlijk onmiddellijk na de klik geladen, kan de JavaScript-uitvoering worden onderbroken en gaat een aanzienlijk deel van de klikgegevens niet naar GA.

Besluit

Gebruik de navigator.sendBeacon-methode die wordt beschreven in Google Help. Helaas wordt het niet door alle browsers ondersteund, maar u zult ermee moeten leven.

Een alternatieve oplossing voor het probleem zou zijn om het laden van de productkaartpagina na een klik te vertragen, zodat de gegevens vrijwel zeker tijd hebben om te worden overgedragen. We raden het echter af om het te gebruiken, omdat latentie de gebruikerservaring negatief kan beïnvloeden. Naar onze mening is het in dit geval beter om wat gegevens te verliezen over klikken van gebruikers van wie de browser de methode navigator.sendBeacon niet ondersteunt.

Een vergelijkbare situatie doet zich soms voor bij het overdragen van transactiegegevens, aangezien sommige online winkels de gebruiker onmiddellijk omleiden van de “Bedankt voor bestelling” pagina (waar transactiegegevens worden overgedragen) naar de betalingssysteempagina voor online betaling. In dit geval raden we je aan om een ​​vertraging van enkele seconden toe te voegen voor de omleiding. Om verwarring bij de gebruiker door latentie te verminderen, kunt u een aftelling toevoegen aan de omleiding.

Of ga over naar de betaalpagina-handleiding door op de knop “Betalen” te klikken.

Situatie 4: onvermogen om transactiegegevens van de site over te dragen

Wanneer gegevens overdragen – na het plaatsen van een bestelling of na betaling?

Een typisch geval: na het plaatsen van een bestelling wordt de gebruiker doorgestuurd naar de pagina “Bedankt voor de bestelling” en is er een aanvullende actie vereist om te betalen. Meestal moet u op de knop “ga naar betaling” klikken, die u doorverwijst naar de betalingsgateway.

Gewoonlijk is alles hier eenvoudig: u kunt de overdracht van gegevens over een succesvolle bestelling configureren op de pagina “Bedankt voor de bestelling”, het script heeft tijd om te laden.

Atypisch geval: na het afrekenen wordt de gebruiker onmiddellijk automatisch naar de betalingsgateway gestuurd voor betaling. Het script voor het overdragen van gegevens over de transactie heeft geen tijd om te verwerken (neem aan dat er geen vertraging is voor de omleiding).

Het lijkt erop dat het in dit geval mogelijk zou zijn om transactiegegevens over te dragen na betaling, d.w.z. wanneer de gebruiker van de betalingsgateway terug naar de site wordt overgebracht. Maar ten eerste mag de gebruiker niet wachten op de omleiding terug naar de site, en ten tweede is er misschien helemaal niet zo’n omleiding. Het is dus niet betrouwbaar.

Oplossingsoptie

Met behulp van het Measurement Protocol kunt u transactiegegevens rechtstreeks van CRM naar Analytics overbrengen. In de meeste gevallen werkt deze optie prima. Gedetailleerde instructies over het meetprotocol vindt u in Google Help.

Aanvullende opmerkingen

Meestal kunt u ook het Measurement Protocol gebruiken als u alleen gegevens van echte bestellingen in Analytics wilt zien.

Een afweging – in een typisch geval kunt u de gegevensoverdracht van de pagina “Bedankt voor bestelling” gebruiken en bovendien een gebeurtenis verzenden met de transactie-ID en betalingsstatus via het Measurement Protocol. Vervolgens kunt u een rapport maken waarin u alle bestellingen ziet die eenvoudig door gebruikers zijn geplaatst en alle bestellingen die met succes zijn betaald.

Situatie 5: e-commercetrechterstappen overslaan

E-commerce sites hebben een atypische structuur, waarin sommige stappen niet expliciet worden gepresenteerd. Als u bijvoorbeeld op de knop “kopen” klikt, wordt het product niet aan de winkelwagen toegevoegd, maar wordt de gebruiker onmiddellijk naar de kassa gestuurd. Dit omvat ook een aankoop met één klik: er is geen toevoeging aan de winkelwagen en een volledige kassa.

Als we niets doen, zien we de gemiste stappen in de trechter in e-commercerapporten en zullen de gegevens moeilijker te navigeren zijn.

Oplossingsoptie

Roep meerdere scripts achter elkaar op om de ontbrekende stappen in te vullen. Als u bijvoorbeeld gegevens over een aankoop met één klik overzet nadat u het formulier “kopen met één klik” heeft ingediend, roept u de scripts voor toevoegen aan winkelwagentje, afrekenen en kopen op volgorde op. Dan zijn er minder hiaten in de verkooptrechter in Google Analytics.

Toegevoegd commentaar

Er is een alternatieve mening dat het niet nodig is om opzettelijk gegevens in analysesystemen te vervormen door “correcte” gegevens (met onderbrekingen) te vervangen door “gemakkelijke” gegevens (zonder onderbrekingen in de trechter). Aangezien er geen eenduidig ​​antwoord is en het onderwerp een lange discussie kan zijn, kunnen we alleen maar aanraden om verschillende opties te testen. U kunt bijvoorbeeld twee weergaven maken in Google Analytics, de ene om gebeurtenissen uit te filteren die de verkooptrechter kunstmatig vullen, en de andere om niet te filteren. Na een tijdje kunt u uw gegevens inzien en beslissen welke optie het beste bij u past.

Situatie 6: dubbele transacties

Wanneer u naar de pagina “Bedankt voor uw bestelling” gaat, worden gegevens over een succesvolle aankoop verzonden, maar de gebruiker kan deze pagina meerdere keren bezoeken. Sommige klanten voegen bijvoorbeeld een bladwijzer toe aan de pagina “Bedankt voor de bestelling” en beginnen vervolgens elke keer met hun bezoek en elke keer dat de transactiegegevens worden verzonden. Hierdoor kunt u dubbele bestelgegevens in de rapporten opmerken.

De eerste oplossing

Maak de pagina “Bedankt voor bestelling” slechts één keer beschikbaar voor elke specifieke bestelling. Dat wil zeggen dat de gebruiker deze pagina niet meer dan één keer kan bezoeken, zelfs als hij de pagina gewoon vernieuwt. Dit betekent dat gegevens niet meer dan één keer kunnen worden overgedragen.

Tweede optie

Zorg ervoor dat het script voor het overdragen van transactiegegevens slechts één keer wordt geactiveerd, zelfs als de pagina meerdere keren kan worden geopend. Een analoog van de eerste optie, maar met behoud van de mogelijkheid om opnieuw naar de pagina “Bedankt voor bestelling” te gaan.

Derde optie

Sla de transactie-ID op in cookies en controleer bij het overbrengen van gegevens over de transactie naar GA elke keer of er al een transactie met deze ID in de cookie is geschreven. Als dit het geval was, stuur dan geen gegevens.

Plus de derde optie – het wordt volledig geïmplementeerd met Google Tag Manager, dat wil zeggen dat de deelname van ontwikkelaars niet nodig is.

En de keerzijde: als de gebruiker de cookies wist, werkt deze methode niet meer. Het wissen van cookies is echter een vrij zeldzaam geval, dus als de eerste en tweede oplossing onmogelijk, tijdrovend of duur zijn, is de derde optie prima.

Gevolgtrekking

Uiteraard zijn niet alle problemen die u kunt tegenkomen bij het opzetten van e-commerce hierboven beschreven, maar we durven aan te nemen dat dit de meest voorkomende zijn. We hopen dat dit artikel je heeft geholpen.

Neem contact met ons op en we bespreken verschillende mogelijkheden.

E-mail: info@webdevelopmentapp.com 
BE: +32 499 41 46 24 
Franklin Rooseveltplaats 12, 2060 Antwerpen, Belgie

web developer