Szerveroldali követés: Definíció és működése

A szerveroldali követés az a gyakorlat, amikor a marketing- és analitikai eseményeket egy általad irányított szerverről gyűjtik és küldik, ahelyett, hogy teljes mértékben a vásárló böngészőjében futó szkriptekre támaszkodnának a címkék és pixelek aktiválásához. Ahelyett, hogy a böngésző közvetlenül tucatnyi harmadik féltől származó követő szkriptet töltene be, az eseményeket egyszer rögzíti a saját backend-ed vagy egy szerveroldali konténer, majd továbbítja azoknak a hirdetési platformoknak és analitikai eszközöknek, amelyeknek szükségük van rájuk.

Miért váltotta fel a csak böngészős követést#

A böngészőalapú követő pixelek és címkék attól függenek, hogy a böngésző ténylegesen végrehajtja-e a harmadik féltől származó JavaScriptet, amit az adblockerek, a böngésző követésgátló funkciói és a lassú oldalbetöltések is megakadályozhatnak. Egy szerveroldali beállítás teljesen kiviszi az adatgyűjtés pontját a böngészőből: a saját szervered rögzíti az eseményt, amikor az ténylegesen bekövetkezik, például a pénztárrendszeredben, és onnan küldi tovább, ami sokkal kevésbé törékeny.

Gyakori implementációk#

Egy first-party követési domain a címkekéréseket a saját aldomaineden keresztül irányítja, nem egy harmadik féltől származón, így a böngészőszintű adblockerek kevésbé valószínű, hogy megjelölik a forgalmat. Egy szerveroldali címke-kezelő konténer, amelynek a leggyakoribb példája a Google Tag Manager szerveroldali opciója, egyetlen szervervégpontot biztosít, amely fogadja az eseményeket és szétosztja azokat több célállomásra. Platform-specifikus esemény API-k közvetlenül egy hirdetési hálózat szervereire küldik az eseményeket. Az affiliate vagy CPA beállításokban egy postback URL valami hasonlót ér el, lehetővé téve, hogy a hálózat szervere közvetlenül értesítse a szerveredet, vagy fordítva, amikor egy konverzió befejeződik.

Mit javít és mit nem#

A szerveroldali követés általában javítja a konverziókövetés teljességét, mivel az események már nem függenek egy érintetlen böngésző-munkamenettől. Csökkentheti az oldalbetöltési súlyt is, mivel kevesebb harmadik féltől származó szkriptnek kell kliensoldalon futnia. Önmagában nem oldja meg az attribúciót több csatorna között; egy jól rögzített eseményhez továbbra is szükség van egy modellre, amely eldönti, hogy mennyi kredit jár az egyes érintési pontoknak. A szerveroldali követés biztosítja, hogy az esemény egyáltalán létezik. Nem dönti el, hogy ki kap érte kreditet.

Beállítási szempontok#

A követés szerveroldalra helyezése valóban több mérnöki munka, mint egy pixel-kódrészlet beillesztése egy oldalba: szükséged van egy megbízható esemény-folyamra, egy módszerre az ugyanazon konverzióhoz kliens- és szerveroldalon egyaránt rögzített események deduplikálására, valamint folyamatos karbantartásra, amint az egyes hirdetési platformok frissítik API-jukat. A legtöbb csapat a legnagyobb értékű konverziós eseménnyel, egy teljesített vásárlással kezd, és onnan bővít, ahelyett, hogy minden címkét egyszerre migrálná. Konzisztens kattintáskövetési azonosítók minden hálózaton sokkal kevésbé fájdalmassá teszik ezt a deduplikációs lépést.

Ahol a pontos követés a legfontosabb#

A tisztább konverziós adatok akkor fizetik meg leginkább magukat, amikor több, eltérő követési megbízhatóságú hirdetési hálózat teljesítményét hasonlítod össze. Egy gyengébb natív pixel-támogatással rendelkező hálózat mesterségesen rosszabbnak tűnhet az irányítópultodon pusztán a követési veszteség miatt, nem azért, mert a forgalom valóban alacsonyabb minőségű. Mielőtt a követés által befolyásolt összehasonlítás alapján újraosztanád a költségvetést, ellenőrizd, hogy mi fut valójában és mennyi ideig az egyes hálózatokon. Az OpenAdLibrary hirdetési intelligencia platformja betekintést nyújt a versenytársak hirdetés-hosszú élettartamába és kreatív mennyiségébe hálózatonként, egy független jelzésként a saját követési számaid mellett.