Cloudflare Zaraz för WooCommerce: e-handelshändelser, samtycke och testning

Cloudflare Zaraz kan skicka e-handelshändelser som stöds till analys- och annonsverktyg, men WooCommerce behöver fortfarande en pålitlig källa för produkt-, varukorgs-, kassa- och orderdata. En lösning i produktion beror på integrationsvägen, tydliga samtyckesregler och tester som jämför spårningen med butikens verkliga ordrar.

Vad ändrar Cloudflare Zaraz i spårningen för WooCommerce?

Zaraz dirigerar åtgärder från tredjepartsverktyg som stöds via Cloudflare. WooCommerce eller en integration måste fortfarande skicka ut handelshändelser och data, och varje mottagarverktyg, plugin och kassaflöde behöver en egen kompatibilitetskontroll.

Zaraz erbjuder ett webb-API för e-handel med namngivna händelser genom hela köpresan, från produkt- och varukorgsaktivitet till slutförda och återbetalda ordrar. Cloudflares referens listar 19 händelsenamn som stöds, kräver att e-handelsspårning är aktiverad i kontot och för varje mottagande verktyg och varnar för att stora orderdata kan överskrida ett mottagarverktygs gränser.

WooCommerce är fortfarande källan till handelsstatusen. Det vet vilken produkt kunden valde, vad som ligger i varukorgen och om en order har nått den status som ditt företag räknar som ett köp. Zaraz skickar vidare händelserna till de konfigurerade verktygen.

En händelse kan synas i Zaraz och ändå inte nå ett mottagarverktyg: åtgärden är avstängd, innehållet matchar inte det verktyget förväntar sig, verktyget stöder inte händelsen automatiskt eller samtycket blockerade den.

Att flytta spårningsåtgärder till Zaraz kan minska antalet tredjepartsskript som webbläsaren kör direkt. Flera verktyg, bland annat Facebook-verktyget i Zaraz, skickar sina anrop från Cloudflares edge i stället för att ladda ett skript från leverantören. Zaraz-laddaren körs fortfarande och vissa verktyg körs fortfarande i webbläsaren, så mät produkt-, varukorgs- och kassasidor före och efter ändringen. IMADOs arbete med hastighetsoptimering av WordPress kan omfatta den mätningen när ändringar i spårningen ingår i en bredare prestandagenomgång.

Hur ska WooCommerce-händelser kopplas till e-handelshändelserna i Zaraz?

Använd ett dokumenterat händelsekontrakt för produkt, varukorg, kassa och order, med konsekventa produkt-ID:n, order-ID:n, valuta, antal och värden. Skicka Order Completed först när butikens köpvillkor är uppfyllt.

Ett minimalt Order Completed-anrop med de fält som Zaraz dokumenterar ser ut så här:

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 }
  ]
});

Bestäm om företaget rapporterar en order när betalningen är auktoriserad, dragen eller när en annan orderstatus har nåtts. Det spelar roll för banköverföring, postförskott, betalningsomdirigeringar och prenumerationer, där slutförd kassa och betalningsavräkning sker vid olika tidpunkter.

Variabla produkter behöver en genomtänkt ID-regel

Många kunder öppnar en variabel produkt och väljer aldrig någon variant. Produktflöden skiljer sig också åt: ett Google Merchant Center-flöde listar ofta varianter, medan Metas kataloger grupperar varianter under en överordnad produkt. En praktisk regel är en produktvisning per sidladdning: skicka variantens ID när det finns en standardvariant eller vald variant, och skicka annars det överordnade ID:t med contenttype: productgroup till Meta. Skicka inte en ny visning varje gång kunden byter variant.

Håll beloppsfält och produkt-ID:n konsekventa

Använd ett stabilt order-ID för att stämma av köp mellan WooCommerce och analys, och återanvänd det som händelse-ID så att mottagarverktygen kan ta bort dubbletter vid nya försök. Skicka valutan uttryckligen. Skriv ner om köpvärdet inkluderar moms och frakt och hur rabatter hanteras, och koppla sedan fälten på samma sätt för alla mottagarverktyg. Om ett verktyg får ett bruttobelopp och ett annat ett nettovärde för varorna kommer rapporterna att skilja sig åt, även om båda dataflödena fungerar.

Behandla kassablock och betalningsomdirigeringar som separata testfall

Ett klick på ”Slutför beställning” startar kassan. Valideringen kan misslyckas, en leverantör kan neka en debitering eller en omdirigering kan komma tillbaka utan en lyckad order. Skicka köpintäkt först när WooCommerce eller betalflödet bekräftar den.

Klassisk kassa, Checkout Block, AJAX-varukorgar, snabbetalningsknappar och externa betalsidor exponerar olika händelser och returvägar. Lyssna på pluginpunkterna i den kassa du faktiskt använder och kontrollera resultatet mot den slutliga orderposten.

WooCommerce-plugin eller egen koppling av Zaraz-händelser?

Använd en underhållen integration när den stöder din kassa, ditt samtyckesupplägg, dina mottagarverktyg och ditt händelsekontrakt. Välj en egen koppling när kassan eller orderreglerna kräver kontroll som pluginet inte ger.

Innan du tar ett plugin i bruk, bekräfta att:

• Det stöder din WooCommerce-version, kassatyp, dina betalmetoder och produkttyper.
• Det skickar de händelsenamn och fält som dina mottagarverktyg kräver.
• Dess samtyckesintegration fungerar med din samtyckeslösning.
• Du kan granska, exportera och återställa Zaraz-konfigurationen.
• Teamet vet vilket system som äger varje händelse och var felsökningen ska ske.

Innan du importerar en genererad Zaraz-konfiguration, gå igenom de utlösare, åtgärder och verktygsinställningar den ändrar, testa den i en kontrollerad miljö och bekräfta hur ändringen kan rullas tillbaka. En granskning av WordPress-webbplatsen kan gå igenom befintliga plugin, spårning och kassaflöde innan du väljer.

En egen koppling passar oftast för anpassade kassor, prenumerationer, fördröjd betalningsbekräftelse, regler för flera valutor, orderstatus som styrs av ett affärssystem eller en blandning av signaler från webbläsare och server. Den låter utvecklare bestämma när händelser utlöses och hur nya försök, återbetalningar och dubblerade callbacks hanteras, och den behöver en ägare när WooCommerce, betallösningar eller plugin ändras.

En hybrid kan fungera: ett plugin för vanliga produkt- och varukorgshändelser och en liten egen integration för en särskild köp- eller återbetalningsregel. Ha en enda sanningskälla per händelse. Överlappande plugin, Google Tag Manager-taggar och Zaraz-åtgärder för samma pixel kan räkna ett köp flera gånger.

Om du väger de här alternativen mot varandra för en butik med anpassad kassa eller flera annonsplattformar, prata med IMADOs WooCommerce-utvecklare innan du bestämmer dig.

Hur ska samtycke konfigureras för Cloudflare Zaraz i WooCommerce?

Koppla varje tredjepartsverktyg till ett uttryckligt samtyckesändamål och kontrollera sedan att nekat samtycke stoppar det. Enligt Cloudflares dokumentation om Consent Management har varje verktyg ett ändamål, och ett verktyg utan tilldelat ändamål hoppar som standard över samtyckeskontrollen, så ett nytillagt verktyg kan kringgå spärren om ingen kopplar det.

Gör samtyckesinventeringen till en del av checklistan inför lansering: varje verktyg, dess ändamål, mottagaren, händelserna det tar emot och samtyckesstatusen det behöver.

Testa åtminstone de här lägena:

• Inget val än: valfria verktyg skickar ingenting före samtycke.
• Nekat samtycke: anropen till verktyget i fråga upphör.
• Givet samtycke: förväntade händelser når verktyget.
• Ändrad inställning: verktyget följer det nya valet efter omladdning.
• Återkommande session: sparade inställningar gäller utan en ny åtgärd i varukorgen eller en ny order.

Kontrollera särskilt den första sidladdningen. Samtyckes-API:t i Zaraz blir oftast tillgängligt först efter att sidans egna skript har körts, så en integration som kontrollerar samtycket direkt kan behandla en besökare som har samtyckt som om hen inte gjort det och kasta händelsen. Vänta på API:t innan du avgör:

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

Om Googles verktyg körs i avancerat läge i Consent Mode v2 kan de fortfarande skicka cookiefria pingar när samtycke är nekat. Bestäm om det stämmer med er policy och testa det uttryckligen.

Håll butikens drift oberoende av spårningen: varukorg, konto och betalning måste fungera när en kund avböjer valfria ändamål. Skicka bara de fält som ett mottagarverktyg behöver och håll personuppgifter utanför delat händelseinnehåll. Zaraz upprätthåller de inställningar du konfigurerar; det är webbplatsens ägare som avgör vilka ändamål och texter som passar varje marknad, så låt den som ansvarar för integritet eller juridik granska dem.

Hur testar du e-handelshändelser i Cloudflare Zaraz före lansering?

Validera en testorder från WooCommerce via Zaraz till varje mottagarverktyg i Preview eller i en testmiljö, och jämför sedan händelser och värden med ordern i WooCommerce. En sida utan JavaScript-fel bevisar inte att ett köp räknades en gång eller att samtycket fungerade.

Följ en testsession och anteckna den förväntade händelsen i varje steg: produktvisning, lägg i varukorg, visning av varukorg, start av kassa, betalningsresultat, köp och återbetalning. Kontrollera källhändelsen, utlösaren och åtgärden i Zaraz och det mottagande verktyget var för sig; ett fel i ett lager ser ut som ett allmänt glapp i den slutliga instrumentpanelen.

Testmatrisen bör omfatta:

• En ny session utan samtyckesval, därefter nekat och givet samtycke, inklusive godkännande på landningssidan.
• En variabel produkt med och utan vald variant, ändrat antal och en borttagen vara.
• Kuponger, rabatter, frakt, moms och varje valuta du rapporterar.
• Varje betalningstyp: nekad, väntande, med omdirigering och lyckad.
• En lyckad order följd av en omladdning av bekräftelsesidan.
• En del- eller helåterbetalning, om du rapporterar återbetalningar.
• Varje kassaväg som butiken använder: Checkout Block, AJAX, prenumeration, snabbetalning.

Spara ID:t för varje testorder och hitta samma ID i mottagarverktyget. Leverantörernas testverktyg hjälper till: Test Events hos Meta visar om en serverhändelse innehöll användardata och produkt-ID:n. Ta bort eventuell testhändelsekod från verktyget innan du publicerar, eftersom händelser som skickas med testkod inte räknas i produktionsrapporteringen.

Använd Zaraz Monitoring för att skilja antalet händelser från utlösare, åtgärder och statusar för anrop på serversidan. Om Zaraz räknade en händelse men mottagarverktyget inte fick den, kontrollera verktygets konfiguration och svaret. Om Zaraz aldrig räknade den, titta på WooCommerce-integrationen och tidpunkten för händelsen. Dokumentera de godkända resultaten och konfigurationsversionen innan du publicerar.

Vad går sönder i produktion?

De mest skadliga problemen är falska och dubblerade köp, kringgånget samtycke och händelser som försvinner utan att någon märker det. Det här är mönstren vi ser oftast när WooCommerce-butiker flyttar spårningen till Zaraz.

E-handelshändelser delas med alla verktyg där e-handel är aktiverat.

Ett zaraz.ecommerce()-anrop når varje verktyg med e-handelsspårning aktiverad, med samma innehåll, och fälten kan inte filtreras per verktyg. Lägg aldrig e-postadresser eller telefonnummer i e-handelshändelser. För verktygsspecifika data skickar du en separat zaraz.track()-händelse med en styrningsegenskap, kopplar den bara till det verktygets utlösare och använder en regel som {{ client._zarazTrack }} lika med viewitem kombinerad med din styrningsflagga.

Helsidescache behåller den gamla spårningslösningen.

Konfiguration och skriptversioner som skrivs in i HTML ligger kvar i Cloudflares och serverns cacher efter en driftsättning. Cachade produkt- och kategorisidor fortsätter att skicka den gamla händelsestrukturen medan ocachade varukorgs- och kassasidor skickar den nya. Rensa sid-, minifierings- och Cloudflare-cacher vid varje ändring av spårningen.

Verktyg på serversidan behöver fortfarande rena identitetsdata.

Facebook-verktyget i Zaraz skickar händelser via Conversions API och hashar själv e-post, telefon och andra användarfält. Skicka normaliserade råvärden: e-post med gemener, telefon med landsnummer, postnummer utan mellanslag eller bindestreck. Värden som redan är hashade hashas två gånger och slutar matcha. Ett stabilt externt ID, till exempel en hash av kundens e-post sparad i en förstapartscookie med HttpOnly, gör att återkommande kunder kan matchas utan att personuppgifter sparas i webbläsaren.

Byte av verktyg nollställer kund-ID:n.

Pixelpluginet som du ersätter har förmodligen skickat sitt eget externa ID i åratal. PixelYourSite skapar till exempel ett slumpmässigt ID och sparar det i en webbläsarcookie (pbid), på kundkontot och i metadata för varje order. Om den nya lösningen i stället börjar skicka en e-posthash ser Meta varje återkommande kund som en ny person, och matchningskvaliteten och kontinuiteten i målgrupperna sjunker. När du planerar migreringen, kontrollera vilka ID:n den nuvarande lösningen sparar och var. Återanvänd dem sedan i en fast ordning: ID:t som sparats på ordern eller kundkontot, den gamla cookien och först därefter en ny e-posthash. Spara det valda ID:t på nya ordrar och konton så att det förblir stabilt från och med då.

Generella uppsamlingsåtgärder skapar dubbletter.

En generell åtgärd för ”alla andra händelser” bredvid egna åtgärder som ViewCategory utlöser båda, om inte den generella utlösaren utesluter varje händelse som har en egen åtgärd. Zaraz begränsar matchningsvärden till 128 tecken, så håll uteslutningsmönstren korta.

Vissa händelser kommer aldrig fram.

Annonsblockerare och automatisk döljning av cookiebanners tar bort en andel av webbläsarens signaler, även WooCommerces egen orderattribuering. Räkna med ett glapp mellan ordrar och attribuerade ordrar, mät det och använd serverbekräftade köp som referens.

Falska köp uppstår när man lyssnar på ett knappklick, ett steg före betalningen eller ett besök på tacksidan utan att kontrollera orderstatusen. Använd en beständig orderreferens och en idempotent regel så att ett nytt försök eller en omladdning inte registrerar ordern igen.

Om flera av de här problemen låter bekanta ligger felet oftast i integrationens utformning och inte i en enskild inställning. IMADOs WooCommerce-team kan granska händelseflödet och rätta det i en testmiljö innan felen når dina rapporter.

När är det värt att ta in utvecklarstöd för en Zaraz-implementering i produktion?

Ta in en WooCommerce-utvecklare när kassaanpassningar, betalningsstatus, samtyckesverktyg eller överlappande analys gör det svårt att bevisa att det finns exakt en giltig händelse per åtgärd i butiken.

En utvecklare tar fram händelsekontraktet tillsammans med marknad och ekonomi, väljer plugin eller egen koppling, testar mot den verkliga kassan och orderns livscykel och dokumenterar vilket verktyg som äger varje händelse och hur samtycket styr den. Det lönar sig när missade eller dubblerade köp påverkar kampanjbeslut, avstämningar eller teamets förtroende för rapporteringen. Efter lanseringen ser WordPress-support och underhåll eller ett underhållsavtal för webbplatsen till att regressionstester förblir en del av lanseringsprocessen när plugin och betallösningar ändras.

Slutsats

En pålitlig Cloudflare Zaraz-lösning för WooCommerce börjar med ett uttryckligt händelsekontrakt, ett samtyckesändamål för varje verktyg, samtyckesmedveten timing på första sidan och testordrar som stämmer med butikens egna data. Välj plugin eller egen koppling utifrån den kassa och de rapporteringsregler du faktiskt använder, och rensa cacher och testa igen vid varje ändring av spårningen.

Planerar du att införa Zaraz eller behöver du rätta en lösning där siffrorna inte går ihop? Prata med IMADO om ditt WooCommerce-projekt.