Konversioonide jälgimine pärast küpsiste kadumist: praktiline juhend signaali kvaliteedi parandamiseks

Sissejuhatus

Kampaania võib tekitada tõelise päringu isegi siis, kui brauseri silt seda kunagi ei registreeri. Küpsiste piirangud, iOS-i privaatsusseaded ja reklaamiblokeerijad võivad suurendada lõhet äritulemuste ja reklaamidashboardide vahel. Lahenduseks ei ole eeldada, et iga puuduv signaal on taastatav. Lahenduseks on luua mõõtmisketi sündmuste ümber, mida ettevõte suudab asjakohaselt koguda, usaldusväärselt edastada ja oma andmetega võrrelda.

Miks on brauseri põhinevad konversiooniarvud muutunud ebatäielikumaks

Brauseri jälgimine sõltub sellest, kas signaalid on kättesaadavad hetkel, mil külastaja jõuab veebisaidile ja sooritab tegevuse. Kolmandate osapoolte küpsiste piirangud võivad raskendada tegevuste seostamist eri veebisaitide vahel. iOS-i privaatsusseaded võivad piirata reklaamijatele kättesaadavaid signaale, samas kui reklaamiblokeerijad võivad takistada mõnede sildite töötamist või päringute saatmist. Need mõjud varieeruvad sõltuvalt brauserist, kasutaja seadistustest, veebisaidi ülesehitusest ja kanalist; see ei tähenda, et iga brauseri konversioon oleks kadunud.

Turundusmeeskonna jaoks on oluline vahet teha puuduva mõõtesignaali ja puuduva äritulemuse vahel. Esitatud päring võib ikkagi ilmuda CRM-süsteemis, isegi kui reklaamiplatvorm ei suuda seda seostada varasema klõpsuga. Vastupidi, platvorm võib kajastada omistatud konversiooni, teadmata, kas sellest päringust sai klient. Mõlema juhtpaneeli käsitlemine täieliku andmekogumina võib moonutada kulutuste ja tulemuslikkuse alaseid otsuseid.

Ehitage alus omaenda sündmuste andmetele

Alustage sellest, et otsustate, millised tegevused on ettevõtte jaoks olulised. Vormi saatmine on kasulik, kuid kvalifitseeritud potentsiaalne klient, broneeritud kohtumine või lõpule viidud müük võivad olla kampaania väärtuse paremad näitajad. Registreerige need etapid süsteemides, mis neid haldavad, ja andke seejärel igale sündmusele selge määratlus. Otsustage näiteks, kas „potentsiaalne klient” luuakse vormi saatmisel või alles pärast selle andmete sisestamist CRM-süsteemi. Kui meeskonnad kasutavad sama nimetust erinevate etappide puhul, levib keerukam jälgimine segadust vaid veelgi kiiremini.

Ühtsed sündmuste nimed, ajamärgised ja lubatud identifikaatorid muudavad andmete seostamise ja auditeerimise lihtsamaks. Koguge ainult kindlaksmääratud eesmärgi jaoks vajalikke andmeid ning tagage, et andmete kogumine ja edastamine toimub kooskõlas kehtivate nõusoleku- ja privaatsuskohustustega. Esmapoolne andmestik kirjeldab suhet andmeid koguva ettevõttega; see ei ole luba kasutada neid andmeid piiranguteta. Reklaamijälgimistarkvara hindamisel otsige toetust olulistele sündmustele ja ärisüsteemidele, selle asemel et eeldada, et pikem funktsioonide nimekiri täidab alusandmete lüngad.

Mida serveripoolne jälgimine ja konversiooni-API-d tegelikult muudavad

Serveripoolne jälgimine muudab sündmuse saatmise viisi. Selle asemel, et tugineda ainult külastaja brauseri päringule, saab sobiva sündmuse edastada serverist või ühendatud ärisüsteemist. See viis võib vähendada sõltuvust ainult brauseri kaudu toimuvast edastamisest ja võimaldab saata hiljem salvestatud tulemusi, nagu kvalifitseeritud potentsiaalne klient või müük. See ei saa luua sündmust, mida kunagi ei kogutud, luua identifikaatorit, mis pole kättesaadav, ega tühistada isiku privaatsusvalikut. Andmete kogumine, edastamine, identiteedi sobitamine ja atribuutika jäävad eraldiseisvateks ülesanneteks.

Platvormid rakendavad neid ülesandeid erinevalt. Meta Conversions API juhendis kirjeldatakse serverisündmuste kasutamist koos Meta Pixeliga ning sündmuste nimede ja ID-de sobitamist, et vältida kattuvate sündmuste kahekordset arvestamist. Google Adsi veebi jaoks mõeldud täiustatud konversioonid täiendavad olemasolevat konversioonimärget räsitud esmapoolse kliendiandmetega, mida Google võib proovida sobitada, vastavalt selle seadistustele ja poliitikanõuetele. See ei ole lihtsalt asendav serverimärge. Ka LinkedIn’i Conversions API dokumentatsioonis kirjeldatakse sündmuse-ID-de dubleerimise vältimist, kui brauseri- ja API-sündmusi kasutatakse koos.

Kohale toimetatud sündmus ei pruugi olla sobitatud või omistatud sündmus. Iga platvorm rakendab oma sobitamis- ja aruandlusreegleid, seega tuleks API kinnitust käsitleda kui tõendit kohaletoimetamise kohta, mitte tõendit selle kohta, et iga konversioon ilmub kampaaniaaruandesse.

Sündmuste täpsuse tagamine sobitamise, dubleerimise eemaldamise ja kvaliteedikontrolli abil

Brauseri- ja serveriteede paralleelne kasutamine võib parandada katvust, kuid tekitab selge riski: sama tegevus võib saabuda kaks korda. Kui mõlemad teed teatavad ühest vormi saatmisest, peavad need sisaldama identifikaatoreid ja sündmuse üksikasju, mida sihtplatvorm vajab kattuvuse tuvastamiseks. ID-d peavad viitama samale aluseks olevale tegevusele, mitte lihtsalt samale külastajale. Lisaks võivad kasulikud sobitamisandmed aidata platvormil seostada sobivat sündmust reklaamiga suhtlemisega, kuigi sobitust ei ole kunagi garanteeritud.

Testige ahelat teadaoleva konversiooniga. Kontrollige, kas brauseri ja serveri kirjed kirjeldavad soovitud tegevust, võrrelge nende sündmuste ID-sid, uurige edastusvastuseid ja vaadake läbi platvormi diagnostika, et leida tagasilükatud või dubleeritud sündmusi. Seejärel võrrelge aluseks olevat tegevust veebisaidi või CRM-i kirjega. Korrake kontrolli, kui vormid, sildiseadistused või CRM-i töövood muutuvad. Erinevused platvormi kogusummade ja sisemiste andmete vahel ei tähenda automaatselt, et integratsioon ei tööta: süsteemid võivad hõlmata erinevaid tegevusi, rakendada erinevaid atribuutsioonireegleid või esitada aruandeid erinevatel kuupäevadel. Erinevuste uurimine algab sündmuste määratlustest, mitte ootusest, et kõik kogusummad peaksid kokku langema.

Seostage kampaaniasignaalid potentsiaalsete klientide ja tuluga

B2B-meeskondade ja pikema müügitsükliga ettevõtete jaoks on vormi täitmine sageli vahepealne sündmus. Mõned päringud muutuvad kvalifitseeritud müügivõimalusteks, teised aga ei arene edasi. Potentsiaalsete klientide hankimise teabe seostamine järgnevate CRM-etappidega aitab meeskonnal eristada kampaaniaid, mis tekitavad aktiivsust, nendest, mis on seotud väärtuslike tulemustega. See nõuab usaldusväärset viisi asjakohase allikateabe säilitamiseks ja potentsiaalsete klientide staatuse uuendamiseks müügiprotsessi edenedes.

LeadJourney keskendub potentsiaalsete klientide ja tulude jälgimisele nii tasuliste, orgaaniliste, AI-otsingu kui ka offline-allikate puhul, integreerides reklaamiplatvorme ja CRM-süsteeme. See ulatus illustreerib, miks konversiooni mõõtmine ei pea piirduma reklaamiplatvormi loendiga: otsingukülastus, telefonikõne ja hiljem sõlmitud tehing võivad kõik anda teavet sama äriküsimuse kohta. Kui allikat ei ole võimalik tulemusega usaldusväärselt seostada, peaksid meeskonnad selle ebakindluse nähtavaks jätma, mitte omistama tulemust oletuste põhjal.

Praktiline mõõtmisrutiin turundajatele

Haldatav rutiin algab ühe äriküsimusega, näiteks millised potentsiaalsete klientide hankimisallikad toovad kvalifitseeritud potentsiaalseid kliente. Valige tulemust määratlev sisemine kirje, dokumenteerige selle loomise aeg ja kaardistage veebisaidi, serveri ja CRM-sündmused, mis peaksid seda esindama. Seejärel viige läbi testkonversioonid asjakohaste teede kaudu. Veenduge, et iga tõeline tegevus toodab soovitud kirje, et dubleeritud brauseri- ja serverisündmused jagavad õiget ID-d ning et tagasilükatud edastusi uuritakse. See annab rohkem teavet kui ainult selle kontrollimine, kas lehel on silt olemas.

Vaadake tulemusi regulaarselt läbi kahel tasandil. Esiteks võrrelge sündmuste mahtu sisemise süsteemiga, et avastada puuduvad või korduvad tegevused. Teiseks võrdle kanaliaruandeid äritulemustega, arvestades samas katvuse ja omistamise erinevusi. Näiteks võib SEO-meeskond uurida, kas orgaaniliste päringute kasvu saadab kvalifitseeritud potentsiaalsete klientide arvu kasv, selle asemel et kasutada edu mõõdikuna ainult liiklust või vormide täitmisi. Kui ilmneb lünk, jälgi selle tekkimist järgmises järjekorras: andmete kogumine, edastamine, sobitamine ja aruandlus. Püsiv konversioonide jälgimine põhineb selgetel sündmuste määratlustel ja korduvatel kontrollidel – mitte API paigaldamisel ja eeldusel, et numbrid on täielikud.