Meta CAPI deduplication τέλος στα διπλά conversions

Ανοίγεις το Meta Ads Manager και βλέπεις ένα εξωπραγματικό ROAS 8x σε μια καμπάνια Advantage+ Shopping. Μπαίνεις όμως στο Shopify ή στο CRM και ο πραγματικός τζίρος είναι ακριβώς ο μισός. Το έχουμε δει δεκάδες φορές σε audits: το Conversions API στέλνει δεδομένα παράλληλα με το browser pixel, αλλά η Meta δεν μπορεί να τα ενώσει, με αποτέλεσμα να μετράει κάθε αγορά δύο φορές.

TL;DR:

• Το διπλό tracking συμβαίνει όταν το web pixel και το CAPI στέλνουν διαφορετικό ή ελλιπές event_id για την ίδια ακριβώς ενέργεια.
• Η Meta χρειάζεται ταυτόσημο συνδυασμό event_name και event_id μέσα σε παράθυρο 48 ωρών για να πετάξει το ένα από τα δύο events.
• Η λύση απαιτεί κοινό transaction identifier από το dataLayer, περασμένο τόσο στο web tag όσο και στο server container μέσω GA4 request.

Γιατί βλέπουμε Facebook Ads διπλά conversions μετά το setup του CAPI

Όταν στήνουμε υβριδικό tracking (browser pixel μαζί με Conversions API), στέλνουμε συνειδητά δύο streams δεδομένων στη Meta για το ίδιο conversion. Ο στόχος είναι να καλύψουμε τις απώλειες από ad blockers, Safari ITP και network drops. Η Meta λαμβάνει το browser payload σε πραγματικό χρόνο και το server payload μερικά milliseconds αργότερα.

Αν δεν δώσεις στη Meta ένα μοναδικό κλειδί ταυτοποίησης για κάθε μεμονωμένη συναλλαγή, ο αλγόριθμος θα υποθέσει ότι πρόκειται για δύο ξεχωριστές αγορές από τον ίδιο χρήστη.

Όταν συμβαίνει αυτό, ο αλγόριθμος bidding βελτιστοποιεί πάνω σε πλασματικά conversion signals. Νομίζει ότι βρήκε ένα κοινό υψηλής αγοραστικής αξίας, ρίχνει εκεί περισσότερο budget και καταστρέφει το scaling της καμπάνιας. Αν θέλεις αξιόπιστα δεδομένα, χρειάζεσαι σωστό server-side tracking με αυστηρό μηχανισμό ελέγχου.

Το κλασικό λάθος με το event id στο Meta Pixel και GTM

Το πιο συνηθισμένο τεχνικό σφάλμα που εντοπίζουμε είναι η χρήση client-side random ID generators χωρίς συγχρονισμό με τον server. Είδαμε setups όπου το Web GTM έτρεχε ένα Custom JavaScript tag με Math.random() για να φτιάξει ένα ID, ενώ το server-side container δημιουργούσε ένα εντελώς διαφορετικό hash κατά την επεξεργασία του GA4 event.

Τα δύο payloads φτάνουν στη Meta με τη μορφή:

• Browser Event: event_name: 'Purchase', event_id: 'rand_839201'
• Server Event: event_name: 'Purchase', event_id: 'srv_940182'

Για τα συστήματα της Meta, αυτά είναι δύο διαφορετικά events. Το deduplication αποτυγχάνει 100% των περιπτώσεων. Το ίδιο συμβαίνει όταν υπάρχει μικρή απόκλιση στο όνομα του event (π.χ. purchase στο web και Purchase στο CAPI), καθώς το matching είναι αυστηρά case-sensitive.

Πώς στήνουμε το Server-side GTM Meta CAPI με σωστό deduplication

Για να λειτουργήσει το deduplication απροβλημάτιστα, πρέπει το αναγνωριστικό να πηγάζει από την ίδια πηγή αλήθειας: το order_id ή transaction_id του ecommerce backend. Στα projects μας ακολουθούμε μια συγκεκριμένη αρχιτεκτονική ροής δεδομένων.

Αυτά είναι τα βήματα υλοποίησης:

1. Ανάγνωση από το dataLayer: Δημιουργούμε μια Data Layer Variable στο Web GTM (π.χ. ecommerce.transaction_id ή transaction_id).
2. Ρύθμιση Web Meta Pixel: Στο Facebook Pixel tag για το Purchase event, ανοίγουμε τα Property Settings / Object Properties και ορίζουμε την παράμετρο event_id με τιμή τη μεταβλητή {{dlv - transaction_id}}.
3. Προώθηση στο GA4 Event Tag: Στο GA4 Purchase event tag (που στέλνει τα δεδομένα στο server container), προσθέτουμε στα Event Parameters την παράμετρο event_id με την ίδια ακριβώς μεταβλητή {{dlv - transaction_id}}.
4. Ρύθμιση στο Server-side GTM: Στο server container, το Meta Conversions API Tag Template (από το Community Template Gallery) διαβάζει αυτόματα το event_id από το εισερχόμενο GA4 request και το προωθεί στο Graph API.

Για non-ecommerce events (όπως ViewContent ή AddToCart) όπου δεν υπάρχει transaction_id, δημιουργούμε ένα unique ID στην αρχή του session ή της σελίδας μέσω GTM Web, το αποθηκεύουμε προσωρινά και το περνάμε ταυτόχρονα και στα δύο tags.

Meta Events Manager deduplication fix: Ο τεχνικός έλεγχος στο Test Events

Αφού κάνουμε publish τις αλλαγές, δεν περιμένουμε απλά να δούμε τις αναφορές στο Ads Manager. Κάνουμε άμεσο validation μέσα από το Meta Events Manager.

Η διαδικασία επαλήθευσης περιλαμβάνει τα εξής σημεία:

• Test Events Tool: Βάζουμε το Test Event Code στο server CAPI tag και ανοίγουμε το console του Test Events tab. Εκτελούμε μια δοκιμαστική αγορά.
• Έλεγχος του Deduplicated Badge: Πρέπει να δούμε δύο γραμμές για το Purchase (μία Browser, μία Server) οι οποίες μέσα σε 2-3 δευτερόλεπτα ενώνονται σε μία εγγραφή με την ένδειξη «Deduplicated».
• Event Parameters Payload: Ελέγχουμε αν το event_id είναι ακριβώς πανομοιότυπο σε χαρακτήρες, χωρίς κενά διαστήματα ή διαφορές σε κεφαλαία/πεζά.
• Event Quality Score: Μέσα σε 24-48 ώρες, το Event Match Quality για το Purchase πρέπει να παραμείνει σταθερό ή να ανέβει (συνήθως πάνω από 7.5/10), χωρίς alerts για duplicate events.

Αν παρατηρείς ασυμφωνίες στα νούμερα του reporting σου, μπορείς να ζητήσεις ένα audit analytics και tracking για να ελέγξουμε αν τα payloads φτάνουν καθαρά στα διαφημιστικά κανάλια. Για περισσότερα τεχνικά teardowns πάνω στη μέτρηση, ρίξε μια ματιά στο blog μας.

Συχνές ερωτήσεις

Πόση ώρα χρειάζεται η Meta για να κάνει deduplicate τα events;

Η διαδικασία γίνεται σχεδόν σε πραγματικό χρόνο στο Test Events tab, αλλά στα reporting dashboards η επεξεργασία ολοκληρώνεται μέσα σε ένα παράθυρο 48 ωρών. Αν το server event φτάσει περισσότερο από 48 ώρες μετά το browser event, η Meta θα το καταγράψει ως ξεχωριστή ενέργεια.

Τι συμβαίνει αν το event_id σταλεί μόνο από τον browser και όχι από τον server;

Αν λείπει το event_id από το ένα από τα δύο endpoints, η Meta δεν μπορεί να εκτελέσει deduplication και θα καταγράψει δύο φορές το conversion. Και τα δύο payloads πρέπει να περιέχουν υποχρεωτικά το ίδιο ακριβώς event_id και event_name.

Γιατί το Event Quality Score παραμένει χαμηλό μετά το deduplication fix;

Το deduplication λύνει μόνο τον διπλασιασμό των events, όχι την ποιότητα των customer information parameters. Για να ανέβει το Event Quality Score χρειάζεται να στέλνεις hashed δεδομένα χρήστη (όπως email, τηλέφωνο, external ID και fbp/fbc cookies) μαζί με το server payload.

Το σωστό measurement δεν είναι ζήτημα τύχης αλλά αυστηρής αρχιτεκτονικής δεδομένων. Όταν εξασφαλίζεις ενιαίο event_id από το dataLayer μέχρι το API endpoint, δίνεις στους αλγορίθμους της Meta καθαρά δεδομένα για να κάνουν σωστό attribution και αποδοτικό scaling.