Ett event-ID ska besvara vilken affärshändelse meddelandet gäller. Ett anrops-ID besvarar vilket leveransförsök som görs. När frågorna blandas ihop kan konverteringar dubbleras eller försvinna. Definiera därför affärsidentiteten innan separata avsändare byggs för webbläsare och server i mätningen för ChatGPT Ads.
Kontraktet är en överenskommelse mellan systemen som observerar handlingen. Det anger när identiteten skapas, var den sparas, hur den når varje avsändare och när en verkligt ny handling behöver ett nytt värde. Här gäller förebyggande design. Felsökning av dubbla event granskar en befintlig implementation som redan ger misstänkta resultat.
Börja med affärshändelsens gräns
För köp behöver verksamheten bestämma vilken auktoritativ handling som betyder att köpet är slutfört. Använd inte slentrianmässigt en sidladdning om samma bekräftelsesida kan laddas flera gånger. Omladdningen är en ny webbläsarhandling men inte nödvändigtvis ett nytt köp.
För leads behöver det avgöras om en rättad inskickning hör till samma leadevent eller utgör en separat handling enligt mätdefinitionen. En teknisk identifierare kan inte lösa en affärsregel som aldrig bestämdes. Skriv regeln med verksamhetsansvarig innan en befintlig postnyckel väljs.
Knyt inte identiteten till ett föränderligt värde som orderns aktuella totalsumma. En priskorrigering ska inte omärkligt skapa ett nytt skenbart köp för att beloppet ingår i ID-formeln. Identitet och attribut beskriver olika saker och behöver kunna hanteras utan att det ena automatiskt ändrar det andra.
Bestäm vem som skapar identiteten
Välj en komponent som skapar eller härleder handlingsidentiteten och sparar den med affärsposten. Övriga komponenter tar emot samma värde i stället för att skapa egna ersättningar. I en vanlig intern modell kan den auktoritativa servern lämna en lämplig eventidentifierare till den tillåtna webbläsarprocessen efter bekräftelse.
Det är en arkitekturrekommendation och inget krav på att alla webbplatser ska implementera samma lösning. Vissa system har redan stabila eventidentiteter medan andra behöver ett särskilt fält. Kontrollera aktuella plattformskrav och egna integritetskrav innan formatet bestäms.
Lägg inte e-postadress, telefonnummer eller andra onödiga personuppgifter i identifieraren. Använd en opak eller annan lämplig intern representation. Syftet är att skilja handlingar åt, inte att sprida kunduppgifter i loggar och nätverksmeddelanden som kan användas av flera personer under felsökning.
Skriv hur värdet mappas mellan vägarna
Mappa webbläsarens alternativfält event_id till servereventets fält id. Båda ska beskriva samma handling och använda samma Pixel ID och eventnamn. Egna event behöver även samma custom_event_name. Skriv in fältnamnen i kontraktet så att teamen kan jämföra sina meddelanden direkt med OpenAI:s exempel för konverteringsspårning och upptäcka skillnader före driftsättning.
Ta ett konkret exempel med påhittade värden. Handlingen purchase-example-82 sparas en gång, skickas av webbläsaren och återanvänds av servern. Om ett serveranrop får timeout behåller nästa försök samma identitet. Nästa verkliga köp får däremot en annan identifierare.
Egna eventnamn behöver ingå när sådana används. Samma ID tillsammans med olika eventnamn uttrycker inte ett gemensamt kontrakt. Styrning av eventnamn beskriver hur namn kan hållas stabila när fler team lägger till handlingar och olika versioner av integrationen ska fungera tillsammans.
Identiteten följer handlingen
- Skapa en gång
Tilldela identitet när den definierade handlingen blir verklig.
- Dela samma värde
Webbläsare och server använder samma sparade eventidentitet.
- Behåll vid omförsök
Ny sändning återanvänder ID; ny handling får ett annat.
Hantera livslängd och kollisioner
Ange hur länge affärssystemet bevarar identiteten för omförsök och felsökning enligt sin policy. Hitta inte på en garanti för hur länge plattformen deduplicerar. Er interna lagring behöver följa stödd leveranshantering och det återställningsutrymme verksamheten kräver.
Bestäm vad som sker om samma identifierare oväntat återanvänds för en annan handling. Konflikten bör bli synlig i stället för att ena avsändaren tyst byter till ett slumpvärde. En ensidig reparation kan förstöra matchningen mellan webbläsare och server och lämna ursprungskollisionen oförklarad.
Ta hänsyn till flera butiker, miljöer eller kunder där interna ordernummer kan upprepas. Designen behöver tillräckligt sammanhang för att undvika oavsiktliga kollisioner inom relevant källa och eventtyp. Håll test och produktion uttryckliga så att säkerheten inte bygger på att utvecklaren minns vilken miljö som är aktiv.
Gör kontraktet prövbart
Skriv ett litet testunderlag: en handling en gång, samma handling på nytt, båda vägar för samma handling, två separata handlingar och omladdad bekräftelsesida. Ange förväntad identitetsrelation i varje fall före implementation. Då blir det möjligt att granska avsikten och inte bara den färdiga koden.
Tester ska kontrollera ID-värdena och inte bara lyckade HTTP-svar. Ett giltigt anrop kan bära fel identitet. Kontrollera även att omförsök bevarar handlingens ursprungliga tid och attribut enligt stödd semantik. Bevara kontraktet hos integrationsansvarig och granska det när checkout, formulär eller sändningskod ändras.
Källgranskning visar vart meddelandena går. Plattformskällorna är OpenAI Conversions API och Measurement Pixel. En bra identitetsdesign gör omförsök odramatiska eftersom alla avsändare vet vilken affärshändelse de beskriver.
Källor och avgränsning
Bestäm hur en affärshändelse får och delar en beständig eventidentitet innan webbläsar- och serverintegration byggs.
Arbetsmetoder och exempel är redaktionella förslag. Kontrollera aktuella plattformsvillkor och funktioner inför genomförandet.