Hoe verschilt serverside tagging van clientside tagging?
Client side tagging is wat het meest gebruikelijk is. Hierbij stuur je vanaf de website events naar verschillende platformen, waaronder Squeezely, maar ook bijvoorbeeld third-parties, zoals Meta, Criteo en Google. De front-end vuurt deze events af en dit zijn verzoeken die je bijvoorbeeld terug vindt in de Netwerk-tab van de developer tools van je browser.
Als er veel partijen worden gekoppeld aan de website voor al je opvolging, kan dit voor vertraging zorgen van je website. Ook zijn deze vaak overal en nergens in te richten, waardoor je het overzicht kan kwijtraken van welke partij, welke data krijgt. Dit laatste is al wat te beperken door veel in te richten via Google Tag Manager.
Wanneer je serverside wilt taggen, gaat de data eerst naar een centraal punt (je server) welke het vervolgens weer uitstuurt naar al deze partijen. Dit gebeurt allemaal op de achtergrond (back-end) en zal je dus op de website (front-end) niet meer terugzien. https://support.google.com/tagmanager/answer/13387731?hl=nl
Wat als ik serverside tagging wil toevoegen aan Squeezely?
Serverside taggen kan met Squeezely, hier zijn een aantal zaken waar je rekening mee moet houden
Script Squeezely
Het script van Squeezely zal nog steeds geladen moeten worden op de website. Dit script zorgt er niet alleen voor dat je makkelijk events naar ons kan sturen, maar ook dat we het first-party cookie kunnen plaatsen, profielen kunnen matchen door een link vanuit de e-mail en personalisaties kunnen tonen. Dit script zal automatisch nog 1 front-end event sturen, namelijk de SessionStart. Dit is een event zonder data, waardoor dit zowel voor gevoelige data als snelheid minimale impact heeft. Wel is deze front-end SessionStart ook essentieel voor Squeezely en Serverside tagging. Deze zorgt er namelijk ook voor dat er een profiel wordt aangemaakt voor het cookie van je bezoeker. Dit is belangrijk voor de volgende stap.
Events vanuit de server
| Note |
|---|
Hieronder volgt een uitleg van de API, bekijk altijd onze API documentatie voor de meest recente base url en authenticatie. Bij veranderingen wordt de API documentatie altijd eerder aangepast dan deze pagina: https://app.squeezely.tech/documentation#backend-api |
Voor het versturen van Events naar Squeezely gebruik je onze API voor backend tracking https://app.squeezely.tech/documentation#backend-tracking
Je doet een POST richting https://api.squeezely.tech/v1/track
Voor de authenticatie hebben we twee headers nodig: X-AUTH-ACCOUNT & X-AUTH-APIKEY De waarden van deze twee headers zijn terug te vinden in de Settings van jouw Squeezely Merchant. Per Merchant merchant zijn er aparte credentials, houdt daar rekening mee als je meerdere merchants in Squeezely hebt.
Vervolgens kan je de benodigde events richting Squeezely sturen. Bekijk deze pagina in onze handleiding voor de meest voorkomende events en hun data: Events.
Wat belangrijk is als je alleen maar serverside gaat sturen is een identifier. Dan is bij ons in volgorde van belangrijkheid een de identifier. In Squeezely kun je de volgende identifiers toepassen (op volgorde van prioritering): userID, email en cookie. Wanneer een bezoeker net op de website landt, dan zal je nog niet direct een userID of email hebben, dus dan zullen we de bezoeker volgen met een cookie. In de API kan je sqzly_cookie meesturen om de juiste bezoeker te volgen. In tegenstelling tot een userID of e-mailadres kan een profiel niet aangemaakt worden met enkel een cookie in de API. Vandaar dat ons script met de SessionStart op de front-end zo belangrijk zijn. Het De cookie die benodigd is kan je vinden als sqzllocal in de cookies, zie ook Cookies en https://squeezely.atlassian.net/wiki/spaces/SG/pages/2189951055/User+consent+cookie+beheer#Squeezely-cookies.
Een payload voor een ViewContent zou er ongeveer zo uit moeten zien:
| Code Block | ||
|---|---|---|
| ||
{
"events": [
{
"event": "ViewContent",
"sqzly_cookie": "sqzl6548db2900000340e093",
"products": [
{
"id": "833",
"name": "Product 1"
}
],
"custom_field": "jouw custom waarde"
}
]
} |
Ratelimit
Via de API kan je 250 calls per minuut doen, wel kan je 250 events tegelijk sturen indien nodig. De ratelimit wordt gereset op 00 seconden van de minuut. Heb je veel events, kijk dan welke echt noodzakelijk zijn om via de server te versturen, omdat ze de meeste impact hebben of persoonlijke data. Een hybride versie van serverside tagging samen met de ‘normale’ front-end tracking is zeker mogelijk.
Maar hoe zit dat nu met serverside cookies?
De cookies die wij zetten, worden door ons het Squeezely Javascript gezet. Ondanks dat dit deze cookie een first-party cookie is, worden de regels steeds strenger en worden cookies die door Javascript worden gezet sneller verwijderd . Door (door Safari zelfs al na 7 dagen). Op het moment dat de cookie vervolgens wordt gezet/ overschreven door de server volgens de browsers (vooralsnog) de einddatum die je er zelf aan geeft. Hoe je het de Squeezely cookie overschrijft kan je hier vinden in onze handleiding: https://squeezely.atlassian.net/wiki/spaces/SG/pages/2158100481/ITP+First+Party+Cookies#Oplossing---cookie-op-serverniveau-herschrijven
Hoewel het ook op serverniveau wordt gedaan, is dit niet gerelateerd of noodzakelijk voor serverside tracking. Als je veel bezoekers op Safari hebt, is dit zeker aan te raden.
Omzeil ik Adblockers met Serverside tagging?
Hoewel veel via de backend wordt gestuurd en dat kan schelen, heb je nog steeds het Squeezely script en de Squeezely cookie nodig om het profiel aan te maken. Wel kan je ons script via een subdomein van jouw site inladen via de zogenaamde CNAME cloaking. Hiermee kan je niet alle , maar zeker wel veel adblockers , omzeilen. Wat dit precies inhoudt en hoe je het inregelt in Squeezely kan je hier vinden: Custom tracker domain (EN)