Ga naar de inhoud
Van een klant kreeg ik de volgende vraag; “Ik zou op de dealerlocator van mijn bedrijfswebsite willen meten hoeveel keer elke dealer zichtbaar wordt na een zoekactie.” Iedere dealer heeft een andere id, dus in principe zou je op basis van deze unieke ID met element visibility triggers kunnen werken, maar dan ga je al snel heel veel verschillende tags aanmaken. eentje voor elke dealer. Dat kan beter;
Future-proof tracking: de oplossing
Wanneer we gaan kijken in de websitecode zien we dat er een aantal elementen zijn die we kunnen gebruiken: elke vestiging heeft een class en een unieke ID zo te zien. Hier kunnen we iets mee.
Als je in Google Analytics inzichtelijk wil krijgen welke vestigingen er allemaal getoond zijn kan je het volgende doen;
- Pagina url is je dealerlocator www.company.be/winkels. Referrer kan je hier ook eventueel gebruiken.
- Is er een element zichtbaar waarbij “.dealer” in de class voorkomt?
- Log het ID als dit het geval is. Bijvoorbeeld id=”dealer_260″
- Elke keer dat dit plaatsvindt (dus niet 1keer per pagina) –> dit zorgt voor 12 aparte events indien er 12 dealers zichtbaar zijn.
Aparte tags en triggers opzetten voor vertoning van elke aparte vestiging is overbodig. Je bent dan ontzettend veel (onnodig) werk aan het doen. Daarboven is deze methode niet zo future-proof als er een vestiging zou bijkomen.
Alles oplossen met zo weinig mogelijk tags & triggers
De opzet is om het simpel te houden. En waar mogelijk maken we gebruik van variabelen voor id’s of namen van de vestigingen. Op die manier worden ze dynamisch doorgegeven naar Analytics. Kwestie van deze setup te future-proofen.
But hey, simple = good right?
De trigger: Zichtbaarheid van element
Het triggertype is “zichtbaarheid van element”: we willen dat er data naar analytics verstuurd wordt elke keer dat er een vestiging voorkomt op de store locator pagina. Als er 12 dealers zijn op een pagina, dan moeten we 12 keer triggeren.
Het eerste idee was om 1x te triggeren per pagina, en vervolgens alle vestigings-ID’s door te sturen (gescheiden met komma bijvoorbeeld). In Analytics kom je dan geweldig snel in de problemen; Aangezien die Analytics last heeft met zaken op te tellen. >Stel 2 events in Analytics: met in het label ‘id1, id2, id3’ en ‘id2, id3, id4’; in Analytics zullen deze ‘strings’ in 2 aparte lijnen worden gezet, en de id2 en id3 worden NIET bij elkaar opgeteld ondanks het feit dat ze beide 2 keer voorkomen. De data wordt als tekst doorgestuurd, en string ‘id1, id2, id3’ is niet gelijk aan ‘id2, id3, id4’.
Dus 1 keer triggeren pér zichtbaarheid van element, om alle vestigingen apart als waarde één voor één te gaan inputten. Zodat indien een waarde meerdere keren voorkomt Analytics ook de frequentie bijhoudt hoe vaak.
Aangezien de pagina-URL niet veranderde bij het opzoeken van dealers moesten we de checkbox van DOM-wijzigingen waarnemen aanzetten. Aangezien er nieuwe elementen getoond worden terwijl de URL ongewijzigt blijft. En zoals je kan zien in de screenshot hierboven specifiëren we hier dat de trigger enkel mag vuren wanneer we ons op een overzichtpagina bevinden.
De tag: Universal Analytics
De gegevens worden doorgestuud naar Analytics in de vorm van een event. Hier specifiëren we in de categorie en actie waarover het gaat. In het label zetten we een variabele {{Click Text}}. Deze zorgt ervoor dat we de naam van de vestiging gaan doorsturen als extra informatie, waardoor we in analytics niet de ID, maar wel de naam van een vestiging wordt doorgestuurd. Op die manier heb je een overzicht van namen, dat werkt makkelijker dan id’s die je niet kan linken aan locaties.
Oorspronkelijke plan was om de unieke vestigings-ID te gaan gebruiken. Deze gingen we omzetten in de juiste naam van de vestiging. Maar stel dat er een vestiging bijkomt, dan moet deze lookuptable verder aangevuld worden toch? Toch ook niet 100% future-proof. Om toekomstig manueel werk uit de weg te gaan hebben we de inhoud van het label in de UA tag vervangen door {{Click Text}}. Aangezien telkens de exacte naam van de vestiging hier in aan bod kwam konden we deze gebruiken – Zonder dat we deze moeten omzetten aan de hand van een lookuptabel.
Testing: werkt de tracking zoals bedoeld?
In de debug mode in Google Tag Manager gaan we eerst naar de zoekpagina. Wanneer we daar een postcode ingeven krijg je op de resultatenpagina onderstaand resultaat:
De UA tag die we gemaakt hebben is 10 keer afgevuurd (voor de 10 shops die op de pagina stonden). Het werkt dus zoals bedoeld.
Bij het openen van een bepaald event, om na te gaan welke waarden er verstuurd werden naar Google Analytics heb je bovenstaand resultaat. Vestigingsnaam wordt mee verstuurd: check!
De juiste data wordt nu op de juiste moment verstuurd. In Analytics komt deze data binnen onder gedrag>gebeurtenissen>gebeurtenisLabel. Dat is de data die de klant inzichten zal geven, en dat vat ineens het doel samen van zaken door te meten;
>Data op zo’n manier structureren zodat er patronen zichtbaar worden om inzichten uit te halen.
