Cloudflare Zaraz for WooCommerce: netthandelshendelser, samtykke og testing

Cloudflare Zaraz kan sende støttede netthandelshendelser til analyse- og annonseverktøy, men WooCommerce trenger fortsatt en pålitelig kilde til produkt-, handlekurv-, kasse- og ordredata. Et oppsett i produksjon avhenger av integrasjonsveien, tydelige samtykkeregler og tester som sammenligner sporingen med butikkens faktiske ordrer.

Hva endrer Cloudflare Zaraz i et sporingsoppsett for WooCommerce?

Zaraz ruter støttede handlinger fra tredjepartsverktøy gjennom Cloudflare. WooCommerce eller en integrasjon må fortsatt sende ut handelshendelser og data, og hvert mottakerverktøy, hver utvidelse og hver kasseflyt trenger sin egen kompatibilitetssjekk.

Zaraz tilbyr et Web API for netthandel med navngitte hendelser gjennom hele kjøpsreisen, fra produkt- og handlekurvaktivitet til fullførte og refunderte ordrer. Cloudflares referanse lister opp 19 støttede hendelsesnavn, krever at netthandelssporing er slått på i kontoen og for hvert mottakende verktøy, og advarer om at store ordredata kan overskride et mottakerverktøys grenser.

WooCommerce er fortsatt kilden til handelsstatusen. Det vet hvilket produkt kunden valgte, hva som ligger i handlekurven, og om en ordre har nådd statusen virksomheten din regner som et kjøp. Zaraz sender hendelsene videre til de konfigurerte verktøyene.

En hendelse kan dukke opp i Zaraz og likevel ikke nå et mottakerverktøy: handlingen er slått av, innholdet stemmer ikke med det verktøyet forventer, verktøyet støtter ikke hendelsen automatisk, eller samtykket blokkerte den.

Å flytte sporingshandlinger til Zaraz kan redusere antallet tredjepartsskript nettleseren kjører direkte. Flere verktøy, blant dem Facebook-verktøyet i Zaraz, sender forespørslene sine fra Cloudflares edge i stedet for å laste inn et skript fra leverandøren. Zaraz-lasteren kjører fortsatt, og noen verktøy kjører fortsatt i nettleseren, så mål produkt-, handlekurv- og kassesider før og etter endringen. IMADOs arbeid med hastighetsoptimalisering av WordPress kan omfatte denne målingen når sporingsendringer er en del av en bredere ytelsesgjennomgang.

Hvordan bør WooCommerce-hendelser kobles til netthandelshendelsene i Zaraz?

Bruk én dokumentert hendelseskontrakt for produkt, handlekurv, kasse og ordre, med konsekvente produkt-ID-er, ordre-ID-er, valuta, antall og verdier. Send Order Completed først når butikkens kjøpsbetingelse er oppfylt.

Et minimalt Order Completed-kall med feltene Zaraz dokumenterer, ser slik ut:

zaraz.ecommerce('Order Completed', {
  order_id: '10482',
  total: 349.00,
  revenue: 300.81,
  tax: 48.19,
  shipping: 0,
  currency: 'PLN',
  products: [
    { product_id: '275333', sku: 'DDS-M1', name: 'Silk scarf', variant: '63 x 63 cm', price: 349.00, quantity: 1 }
  ]
});

Bestem om virksomheten rapporterer en ordre når betalingen er autorisert, trukket eller når en annen ordrestatus er nådd. Dette betyr noe for bankoverføring, oppkrav, betalingsviderekoblinger og abonnementer, der fullført kasse og oppgjør skjer på ulike tidspunkt.

Variable produkter trenger en gjennomtenkt ID-regel

Mange kunder åpner et variabelt produkt uten å velge en variant. Produktfeeder er også forskjellige: en Google Merchant Center-feed lister ofte opp varianter, mens Meta-kataloger grupperer varianter under et overordnet produkt. En praktisk regel er én produktvisning per sideinnlasting: send variant-ID-en når det finnes en standard- eller valgt variant, og ellers den overordnede ID-en med contenttype: productgroup til Meta. Ikke send en ny visning hver gang kunden bytter variant.

Hold beløpsfelt og produkt-ID-er konsekvente

Bruk en stabil ordre-ID til å avstemme kjøp mellom WooCommerce og analyse, og gjenbruk den som hendelses-ID slik at mottakerverktøyene kan fjerne duplikater ved nye forsøk. Send valutaen eksplisitt. Skriv ned om kjøpsverdien inkluderer mva. og frakt og hvordan rabatter behandles, og koble deretter disse feltene likt for alle mottakerverktøy. Hvis ett verktøy får en bruttosum og et annet en netto vareverdi, vil rapportene avvike selv om begge datastrømmene fungerer.

Behandle kasseblokker og betalingsviderekoblinger som egne testtilfeller

Et klikk på «Legg inn bestilling» starter kassen. Valideringen kan feile, en leverandør kan avvise en belastning, eller en viderekobling kan komme tilbake uten en vellykket ordre. Send kjøpsinntekt først når WooCommerce eller betalingsflyten bekrefter den.

Klassisk kasse, Checkout Block, AJAX-handlekurver, hurtigbetalingsknapper og eksterne betalingssider gir ulike hendelser og returveier. Lytt til utvidelsespunktene i kassen du faktisk bruker, og kontroller resultatet mot den endelige ordreposten.

WooCommerce-utvidelse eller egen kobling av Zaraz-hendelser?

Bruk en vedlikeholdt integrasjon når den støtter kassen, samtykkeoppsettet, mottakerverktøyene og hendelseskontrakten din. Velg egen kobling når kassen eller ordrereglene krever kontroll som utvidelsen ikke gir.

Før du tar i bruk en utvidelse, bekreft at:

• Den støtter din WooCommerce-versjon, kassetype, betalingsmetoder og produkttyper.
• Den sender hendelsesnavnene og feltene mottakerverktøyene dine krever.
• Samtykkeintegrasjonen fungerer med samtykkeløsningen din.
• Du kan se, eksportere og gjenopprette Zaraz-konfigurasjonen.
• Teamet vet hvilket system som eier hver hendelse, og hvor feil skal feilsøkes.

Før du importerer en generert Zaraz-konfigurasjon, gå gjennom utløserne, handlingene og verktøyinnstillingene den endrer, test den i et kontrollert miljø og bekreft hvordan endringen kan rulles tilbake. En gjennomgang av WordPress-nettstedet kan se på eksisterende utvidelser, sporing og kasseflyt før du velger.

Egen kobling passer som regel for tilpassede kasser, abonnementer, forsinket betalingsbekreftelse, regler for flere valutaer, ordrestatus styrt av ERP eller en blanding av signaler fra nettleser og server. Den lar utviklerne bestemme når hendelser utløses og hvordan nye forsøk, refusjoner og dupliserte callbacks håndteres, og den trenger en eier når WooCommerce, betalingsløsninger eller utvidelser endres.

En hybrid kan fungere: en utvidelse for standard produkt- og handlekurvhendelser og en liten egen integrasjon for en spesiell kjøps- eller refusjonsregel. Ha én sannhetskilde per hendelse. Overlappende utvidelser, Google Tag Manager-tagger og Zaraz-handlinger for samme piksel kan telle ett kjøp flere ganger.

Hvis du vurderer disse alternativene for en butikk med tilpasset kasse eller flere annonseplattformer, snakk med IMADOs WooCommerce-utviklere før du bestemmer deg.

Hvordan bør samtykke konfigureres for Cloudflare Zaraz i WooCommerce?

Knytt hvert tredjepartsverktøy til et eksplisitt samtykkeformål, og kontroller deretter at avslått samtykke stopper det. Cloudflares dokumentasjon for Consent Management sier at hvert verktøy har ett formål, og at et verktøy uten tildelt formål som standard hopper over samtykkesjekken, så et nylig lagt til verktøy kan omgå sperren hvis ingen kobler det.

Gjør samtykkeoversikten til en del av sjekklisten før lansering: hvert verktøy, formålet, mottakeren, hendelsene det mottar og samtykkestatusen det trenger.

Test minst disse tilstandene:

• Ikke valgt ennå: valgfrie verktøy sender ingenting før samtykke.
• Samtykke avslått: forespørslene til det aktuelle verktøyet stopper.
• Samtykke gitt: forventede hendelser når verktøyet.
• Endret preferanse: verktøyet følger det nye valget etter ny innlasting.
• Returnerende økt: lagrede preferanser gjelder uten en ny handling i handlekurven eller en ny ordre.

Sjekk særlig den første sideinnlastingen. Samtykke-API-et i Zaraz blir vanligvis tilgjengelig først etter at sidens egne skript har kjørt, så en integrasjon som sjekker samtykke umiddelbart, kan behandle en besøkende som har samtykket, som om vedkommende ikke har det, og forkaste hendelsen. Vent på API-et før du avgjør:

function onConsentReady(callback) {
  if (window.zaraz && zaraz.consent && zaraz.consent.APIReady) callback();
  else document.addEventListener('zarazConsentAPIReady', callback, { once: true });
}

Hvis Google-verktøy kjører i avansert modus i Consent Mode v2, kan de fortsatt sende informasjonskapselfrie pinger når samtykke er avslått. Bestem om det samsvarer med retningslinjene dine, og test det eksplisitt.

Hold butikkdriften uavhengig av sporingen: handlekurv, konto og betaling må fungere når en kunde avslår valgfrie formål. Send bare feltene et mottakerverktøy trenger, og hold personopplysninger utenfor delt hendelsesinnhold. Zaraz håndhever preferansene du konfigurerer; det er nettstedseieren som bestemmer hvilke formål og tekster som passer for hvert marked, så la den som har ansvar for personvern eller juss, gå gjennom dem.

Hvordan tester du netthandelshendelser i Cloudflare Zaraz før lansering?

Valider en testordre fra WooCommerce via Zaraz til hvert mottakerverktøy i Preview eller i et testmiljø, og sammenlign deretter hendelser og verdier med ordren i WooCommerce. En side uten JavaScript-feil beviser ikke at et kjøp ble telt én gang, eller at samtykket fungerte.

Følg én testøkt og noter forventet hendelse i hvert steg: produktvisning, legg i handlekurv, visning av handlekurv, start av kasse, betalingsresultat, kjøp og refusjon. Sjekk kildehendelsen, utløseren og handlingen i Zaraz og mottakerverktøyet hver for seg; en feil i ett lag ser ut som et generelt hull i det endelige dashbordet.

Testmatrisen bør omfatte:

• En ny økt uten samtykkevalg, deretter avslått og gitt samtykke, inkludert godkjenning på landingssiden.
• Et variabelt produkt med og uten valgt variant, endring av antall og fjerning av en vare.
• Kuponger, rabatter, frakt, mva. og hver valuta du rapporterer.
• Hver betalingstype: avvist, ventende, med viderekobling og vellykket.
• En vellykket ordre etterfulgt av ny innlasting av bekreftelsessiden.
• En delvis eller full refusjon, hvis du rapporterer refusjoner.
• Hver kassevei butikken bruker: Checkout Block, AJAX, abonnement, hurtigbetaling.

Lagre ID-en til hver testordre og finn samme ID i mottakerverktøyet. Leverandørenes testverktøy hjelper her: Test Events hos Meta viser om en serverhendelse inneholdt brukerdata og produkt-ID-er. Fjern eventuell testhendelseskode fra verktøyet før publisering, fordi hendelser sendt med testkode ikke telles i produksjonsrapporteringen.

Bruk Zaraz Monitoring til å skille antall hendelser fra utløsere, handlinger og statuser for forespørsler på serversiden. Hvis Zaraz telte en hendelse, men mottakerverktøyet ikke fikk den, sjekk verktøykonfigurasjonen og svaret. Hvis Zaraz aldri telte den, se på WooCommerce-integrasjonen og tidspunktet for hendelsen. Noter de godkjente resultatene og konfigurasjonsversjonen før publisering.

Hva går galt i produksjon?

De mest skadelige problemene er falske og dupliserte kjøp, omgått samtykke og hendelser som forsvinner i det stille. Dette er mønstrene vi ser oftest når WooCommerce-butikker flytter sporingen til Zaraz.

Netthandelshendelser deles med alle verktøy som har netthandel slått på.

Et zaraz.ecommerce()-kall når alle verktøy med netthandelssporing slått på, med samme innhold, og feltene kan ikke filtreres per verktøy. Legg aldri e-postadresser eller telefonnumre i netthandelshendelser. For verktøyspesifikke data sender du en egen zaraz.track()-hendelse med en rutingegenskap, knytter den bare til utløseren for det verktøyet og bruker en regel som {{ client._zarazTrack }} lik viewitem kombinert med rutingflagget ditt.

Helsidecache beholder det gamle sporingsoppsettet.

Konfigurasjon og skriptversjoner som skrives inn i HTML, blir liggende i Cloudflare- og servercacher etter en utrulling. Bufrede produkt- og kategorisider fortsetter å sende den gamle hendelsesstrukturen, mens ubufrede handlekurv- og kassesider sender den nye. Tøm side-, minifiserings- og Cloudflare-cacher ved hver sporingsendring.

Verktøy på serversiden trenger fortsatt rene identitetsdata.

Facebook-verktøyet i Zaraz sender hendelser via Conversions API og hasher selv e-post, telefon og andre brukerfelt. Send normaliserte råverdier: e-post med små bokstaver, telefon med landkode, postnummer uten mellomrom eller bindestreker. Verdier som allerede er hashet, blir hashet to ganger og slutter å matche. En stabil ekstern ID, for eksempel en hash av kundens e-post lagret i en førstepartscookie med HttpOnly, gjør at returnerende kunder kan matches uten at personopplysninger lagres i nettleseren.

Bytte av verktøy nullstiller kunde-ID-er.

Pikselutvidelsen du erstatter, har sannsynligvis sendt sin egen eksterne ID i årevis. PixelYourSite genererer for eksempel en tilfeldig ID og lagrer den i en nettlesercookie (pbid), på kundekontoen og i metadataene til hver ordre. Hvis det nye oppsettet i stedet begynner å sende en e-posthash, ser Meta hver returnerende kunde som en ny person, og matchkvaliteten og kontinuiteten i målgruppene faller. Når du planlegger migreringen, sjekk hvilke ID-er det nåværende oppsettet lagrer, og hvor. Gjenbruk dem deretter i fast rekkefølge: ID-en som er lagret på ordren eller kundekontoen, den gamle cookien og først deretter en ny e-posthash. Lagre den valgte ID-en på nye ordrer og kontoer, slik at den forblir stabil fra da av.

Oppsamlingshandlinger gir duplikater.

En generell handling for «alle andre hendelser» ved siden av egne handlinger som ViewCategory utløser begge, med mindre den generelle utløseren utelukker alle hendelser som har en egen handling. Zaraz begrenser samsvarsverdier til 128 tegn, så hold utelukkelsesmønstrene korte.

Noen hendelser kommer aldri frem.

Annonseblokkere og automatisk skjuling av cookiebannere fjerner en andel av nettleserens signaler, også WooCommerces egen ordreattribusjon. Regn med et avvik mellom ordrer og attribuerte ordrer, mål det og bruk serverbekreftede kjøp som referanse.

Falske kjøp oppstår når man lytter til et knappeklikk, et steg før betaling eller et besøk på takkesiden uten å sjekke ordrestatusen. Bruk en varig ordrereferanse og en idempotent regel, slik at et nytt forsøk eller en ny innlasting ikke registrerer ordren på nytt.

Hvis flere av disse høres kjent ut, ligger problemet som regel i integrasjonsdesignet og ikke i én enkelt innstilling. IMADOs WooCommerce-team kan gå gjennom hendelsesflyten og rette den i et testmiljø før feilene når rapportene dine.

Når er det verdt å få utviklerhjelp til en Zaraz-implementering i produksjon?

Hent inn en WooCommerce-utvikler når kassetilpasninger, betalingsstatus, samtykkeverktøy eller overlappende analyse gjør det vanskelig å bevise at det kommer nøyaktig én gyldig hendelse per handling i butikken.

En utvikler definerer hendelseskontrakten sammen med markedsføring og økonomi, velger utvidelse eller egen kobling, tester den mot den faktiske kassen og ordrens livssyklus og dokumenterer hvilket verktøy som eier hver hendelse og hvordan samtykke styrer den. Det lønner seg når manglende eller dupliserte kjøp påvirker kampanjebeslutninger, avstemming eller teamets tillit til rapporteringen. Etter lansering sørger WordPress-støtte og vedlikehold eller en vedlikeholdsavtale for nettstedet for at regresjonstester forblir en del av utrullingsprosessen når utvidelser og betalingsløsninger endres.

Konklusjon

Et pålitelig Cloudflare Zaraz-oppsett for WooCommerce starter med en eksplisitt hendelseskontrakt, et samtykkeformål for hvert verktøy, samtykkebevisst timing på første side og testordrer som stemmer med butikkens egne data. Velg utvidelse eller egen kobling ut fra kassen og rapporteringsreglene du faktisk bruker, og tøm cacher og test på nytt ved hver sporingsendring.

Planlegger du å ta i bruk Zaraz, eller må du rette et oppsett der tallene ikke stemmer? Snakk med IMADO om WooCommerce-prosjektet ditt.