Conversions API deduplikatsioon, korralikult tehtud.

Meta Pixeli ja Conversions API koos kasutamine on nüüd tavapärane soovitus, ja see on õige soovitus. Vahele jäetakse aga see osa, mis teeb paari toimivaks: deduplikatsioon. Saada mõlemad ilma selleta ja Meta loeb ühte konversiooni kaks korda. Tee mehhanismis peen viga ja võid paisutada ühe päris konversiooni kümneteks salvestatud sündmusteks, mis kahjustab optimeerimist rohkem kui serveripoolse mõõtmise täielik puudumine.

See on detail, mis eristab CAPI liidest, mis parandab tulemusi, sellest, mis neid vaikselt halvendab. Kui alles seadistad põhitõdesid, alusta meie Meta Pixeli seadistamise juhendist ja tule siis siia tagasi.

Miks deduplikatsioon on olemas

Brauseri Pixel ja Conversions API kirjeldavad sama päriselu sündmust kahest vaatenurgast. Kui keegi ostab, käivitab Pixel tema brauseris Purchase-sündmuse ja su server käivitab Purchase-sündmuse taustsüsteemis. Mõlemad raporteerivad ühte ostu. Meta vajab viisi selle äratundmiseks, muidu täitub su Events Manager olematu mahuga.

Mõlemad saadetakse ikkagi katvuse pärast. Brauserisündmused kaovad reklaamiblokeerijate, privaatsusseadete ja suletud vahelehtede tõttu, sageli 20 kuni 40 protsenti neist. Serverisündmused kaovad siis, kui kasutaja teekond ei jõua kunagi su taustsüsteemi või kui tunnused on sobitamiseks liiga kasinad. Koos katavad nad teineteist. Deduplikatsioon on see, mis hoiab seda kattuvust muutumast topeltloendamiseks.

Kuidas Meta kahte sündmust tegelikult sobitab

Meta deduplitseerib event_name'i ja event_id kombinatsiooni põhjal. Kui deduplikatsiooniakna jooksul saabuvad kaks sama sündmuse nime ja sama sündmuse ID-ga sündmust, käsitleb Meta neid ühe sündmusena ja jätab alles esimesena saabunu, eelistades sobitamiseks tavaliselt rikkamat serveripoolset andmestikku.

See tähendab, et kogu mehhanism toetub ühele asjale: mõlemad saadetised peavad kandma identset ja stabiilset sündmuse ID-d, mis on tuletatud konversioonist endast. Mitte lehe laadimisest, mitte ajatemplist ega saatmise hetkel loodud juhuslikust numbrist.

Kolm asja, mis peavad kokku langema

Esiteks peab sündmuse ID olema mõlemal poolel märk-märgilt identne. Tuleta see millestki, mis on konversioonile olemuslik: tellimuse ID, broneeringu UUID, tehingu viitenumber. Midagi, mille brauser ja server saavad teineteisest sõltumatult välja arvutada ja jõuda sama vastuseni.

Teiseks peab sündmuse nimi täpselt kattuma. Purchase ja purchase ei ole sobitamisloogika jaoks sama sündmus. Brauseri Purchase ja serveri CompletePayment ei deduplitseeru kunagi, ükskõik kui hästi ID-d kokku langevad.

Kolmandaks peavad kaks sündmust saabuma piisavalt lähestikku. Meta deduplikatsiooniaken on helde, aga mitte lõputu, ja päevi hiljem uuesti saadetud sündmused ei sobitu brauserisündmusega, mis on juba aegunud.

Viga 1: uuesti genereeritud sündmuse ID-d

Kõige levinum murdekoht. Brauser genereerib käivitamise hetkel juhusliku sündmuse ID, server genereerib oma, ja need ei kattu kunagi. Iga konversioon loetakse kaks korda. Ads Manageris näib, nagu tulemused oleksid üleöö kahekordistunud, ja see on täpselt seda tüüpi hea uudis, mida keegi ei uuri.

Tunnuseks on konversioonide arv, mis on ligikaudu su tegeliku numbri ümmargune kordne, ja Events Manageri deduplikatsioonimäär nulli lähedal. Meta näitab seda Events Manageri kattuvusdiagnostikas, ja seda tasub kontrollida kohe, kui CAPI käima läheb, mitte kvartal hiljem.

Viga 2: olekuta uuesti saatmine

Seda tasub üksikasjalikult kirjeldada, sest astusime ise sellesse ämbrisse ja dokumentatsioonist see välja ei paista.

Meil jookseb ajastatud töö, mis küsib broneerimissüsteemist andmeid ja saadab iga broneeringu Metale Lead-sündmusena, et väljaspool lehele manustatud vidinat tehtud broneeringud kaotsi ei läheks. Selle esimene versioon saatis igal käivitusel uuesti kõik viimase 48 tunni broneeringud, eeldusel, et Meta enda deduplikatsioon lahendab asja. Sündmuste ID-d olid õiged ja stabiilsed, seega tundus see ohutu.

Ei olnud. Meta deduplitseeris omistamise jaoks õigesti ja Ads Manager näitas õiget päringute arvu. Aga Events Manager loeb iga saabunud sündmust, nii et üks päris broneering saabus kahe päeva jooksul umbes 120 korda. Sobitamise kvaliteet langes 3,3 punktini kümnest ja algoritm optimeeris signaali vastu, mis nägi välja nagu identsete madala kvaliteediga päringute tulv.

Lahendus ei ole nutikamad ID-d, vaid olek. Pea arvestust selle üle, mis on juba saadetud, kontrolli seda enne iga saatmist ja kui kontroll ise ebaõnnestub, jäta saatmata. Meta poolne deduplikatsioon on turvavõrk päris brauseri ja serveri kattuvuse jaoks, mitte luba saata sama sündmust graafiku alusel ikka ja jälle uuesti.

Viga 3: liiga kasinad tunnused

Deduplikatsioon võib töötada laitmatult ja su seadistus võib ikkagi ootustele alla jääda, sest sobitamine ja deduplikatsioon on erinevad probleemid. Serverisündmus, millel pole muud kui IP-aadress ja brauseri tunnus, deduplitseerub ilusti, aga ei sobitu peaaegu kellegagi.

Saada miinimumina räsitud e-post ning lisa räsitud telefon, ees- ja perekonnanimi, linn, riik ning küpsised _fbp ja _fbc, kui need sul on. Räsi SHA-256-ga, teisenda enne seda kõik väiketähtedeks ja eemalda tühikud, ning ära kunagi saada töötlemata isikuandmeid. Iga lisaparameeter tõstab sobitamise kvaliteeti mõõdetavalt, ja just sobitamise kvaliteedi vastu algoritm tegelikult optimeerib.

Kuidas kontrollida, et see töötab

Neli kontrolli, selles järjekorras. Kasuta Events Manageri Test Events tööriista ja tee läbi üks päris konversioon: peaksid nägema nii brauseri- kui ka serverisündmuse saabumist, märgistatuna deduplitseerituks. Vaata sündmuste kattuvusdiagnostikast, et deduplikatsioonimäär oleks kõrge ja stabiilne, mitte nulli ega 100 protsendi lähedal. Võrdle kindla päeva Events Manageri konversioonide arvu oma andmebaasi tegeliku numbriga ja eelda, et need on lähedased. Lõpuks jälgi iga sündmuse Event Match Quality hinnet ja käsitle kõike, mis jääb alla umbes 6, parameetrite, mitte deduplikatsiooni probleemina.

Seejärel tee kogu test kaks korda järjest. Kui su serveripoolne töö hoiab olekut, ei tohiks teine käivitus saata mitte midagi.

Kokkuvõte

Deduplikatsioon ei ole CAPI seadistuses linnuke kontrollnimekirjas, see on asi, mis teeb seadistuse üldse väärtuslikuks. Tuleta sündmuse ID konversioonist, hoia sündmuste nimed identsed, hoia olekut kõige juures, mis jookseb graafiku alusel, ja rikasta serveri andmestikku nii paljude räsitud tunnustega, kui sul on õigustatult olemas. Puhas signaal on väärt rohkem kui lihtsalt rohkem signaali. Korrektne deduplikatsioon on osa iga konto seadistusest meie Meta reklaami teenuses. Kui su raporteeritud ja tegelikud konversioonid on vaikselt lahku triivinud, on see vahe tavaliselt esimene asi, mida tasub parandada, ja see on enamasti odavam kui järjekordne loovmaterjali ring. Tasuta strateegiakõne ütleb, kummaga sul tegemist on.