Τι είναι η server-side παρακολούθηση; Οδηγός για ηλεκτρονικά καταστήματα

Η server-side παρακολούθηση σημαίνει ότι τα συμβάντα μετατροπής, όπως μια αγορά, στέλνονται στις διαφημιστικές πλατφόρμες από έναν server αντί μόνο από ένα script στο πρόγραμμα περιήγησης του αγοραστή. Για ένα ηλεκτρονικό κατάστημα, ο server στέλνει κάθε παραγγελία στη Meta, στο TikTok ή στη Google μέσω των API τους, οπότε η πώληση αναφέρεται ακόμη κι όταν το pixel του προγράμματος περιήγησης είναι μπλοκαρισμένο ή δεν φορτώνει ποτέ.

Ο οδηγός αυτός εξηγεί τη διαφορά ανάμεσα σε ένα pixel προγράμματος περιήγησης και στη server-side παρακολούθηση, ακολουθεί τα δεδομένα από το κλικ στη διαφήμιση μέχρι την πλατφόρμα και δείχνει τι περιέχει ένα συμβάν από τον server. Καλύπτει επίσης την αφαίρεση διπλοεγγραφών, το server-side tagging, τη συγκατάθεση και πώς θα καταλάβετε αν το κατάστημά σας τη χρειάζεται. Για την ίδια τη ρύθμιση στο Shopify, διαβάστε τη server-side παρακολούθηση στο Shopify.

Pixel προγράμματος περιήγησης έναντι server-side παρακολούθησης

Ένα pixel προγράμματος περιήγησης είναι ένα κομμάτι JavaScript από τη διαφημιστική πλατφόρμα. Τρέχει στις σελίδες σας και στέλνει συμβάντα από τη συσκευή του αγοραστή απευθείας στην πλατφόρμα: μια προβολή σελίδας, μια προσθήκη στο καλάθι, μια αγορά στη σελίδα ευχαριστίας. Λειτουργεί μόνο όταν το script φορτώνει, εκτελείται και φτάνει στην πλατφόρμα πριν ο αγοραστής φύγει από τη σελίδα.

Η server-side παρακολούθηση μεταφέρει την αποστολή σε έναν server. Το συμβάν μπορεί να ξεκινά από δεδομένα που το κατάστημά σας έχει ήδη, όπως μια πληρωμένη παραγγελία, και ο server το στέλνει στο API της πλατφόρμας. Η Meta ονομάζει αυτό το API Conversions API και το TikTok το ονομάζει Events API. Το Google Ads χρησιμοποιεί enhanced conversions, που προσθέτουν δεδομένα πελάτη σε μορφή hash σε μια μετατροπή.

Η εκτέλεση και των δύο δίνει στην πλατφόρμα τα πιο πλήρη δεδομένα. Το συμβάν του προγράμματος περιήγησης προσθέτει cookies και πλαίσιο σελίδας. Το συμβάν του server φτάνει ακόμη κι όταν το πρόγραμμα περιήγησης αποτυγχάνει. Ένα κοινό event id εξασφαλίζει ότι η πλατφόρμα μετράει κάθε αγορά μία φορά.

Πώς λειτουργεί η server-side παρακολούθηση;

Η server-side παρακολούθηση για ένα ηλεκτρονικό κατάστημα έχει δύο μισά. Το πρώτο μισό γίνεται στο πρόγραμμα περιήγησης: όταν ένας αγοραστής φτάνει από μια διαφήμιση, ένα script αποθηκεύει το click ID από το URL. Το δεύτερο μισό γίνεται στον server: όταν πληρωθεί η παραγγελία, ο server συνδέει αυτό το click ID με την παραγγελία και στέλνει την αγορά.

Καταγραφή του κλικ

Οι διαφημιστικές πλατφόρμες προσθέτουν ένα click ID στο URL προορισμού: fbclid για τη Meta, ttclid για το TikTok, gclid για το Google Ads και msclkid για το Microsoft Ads. Το click ID είναι ο ισχυρότερος σύνδεσμος ανάμεσα σε μια πώληση και στη διαφήμιση που την προκάλεσε, γι' αυτό πρέπει να αποθηκεύεται στην πρώτη προβολή σελίδας. Οι παράμετροι UTM προσθέτουν τα ονόματα της καμπάνιας, του ad set και της διαφήμισης σε μορφή που ελέγχετε εσείς.

Αντιστοίχιση της παραγγελίας

Στη συνέχεια ο server πρέπει να ξέρει ποιος επισκέπτης έκανε την παραγγελία. Ο πιο αξιόπιστος σύνδεσμος είναι μια τιμή που ταξιδεύει με το καλάθι μέσα στην παραγγελία, όπως ένα ID επισκέπτη που αποθηκεύεται στο καλάθι. Οι άλλες μέθοδοι είναι πιο αδύναμες: μια διεύθυνση email που ο επισκέπτης έδωσε νωρίτερα στο site ή η ίδια διεύθυνση IP και το ίδιο πρόγραμμα περιήγησης λίγο πριν από την παραγγελία. Κάθε πλατφόρμα ηλεκτρονικού καταστήματος προσφέρει διαφορετικές επιλογές. Ο οδηγός μας για άλλα ηλεκτρονικά καταστήματα παραθέτει τις μεθόδους που χρησιμοποιεί το ROASaurus ανά πλατφόρμα.

Αποστολή του συμβάντος

Τέλος, ο server στέλνει την αγορά στο API κάθε πλατφόρμας. Το συμβάν περιλαμβάνει την αξία της παραγγελίας, το click ID και δεδομένα πελάτη που βοηθούν την πλατφόρμα να βρει το άτομο που έκανε κλικ. Αν μια πλατφόρμα δεν λειτουργεί ή επιστρέψει σφάλμα, μια καλή ρύθμιση προσπαθεί ξανά αργότερα, ώστε η αγορά να μη χαθεί.

Τι περιέχει ένα συμβάν από τον server;

Κάθε πλατφόρμα έχει τα δικά της ονόματα πεδίων, αλλά ένα συμβάν αγοράς φέρει παντού τα ίδια είδη δεδομένων. Ακολουθεί ένα συντομευμένο παράδειγμα για το Meta Conversions API:

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1793009700,
    "event_id": "order-1042",
    "action_source": "website",
    "event_source_url": "https://yourstore.com/checkout/thank-you",
    "user_data": {
      "em": ["8c87b489ce35cf2e2f39f80e282cb2e804932a56a213983eeeb428407d43b52d"],
      "ph": ["6d420c869d4eb97fe7de4576c9d04bb34d1a5788e0b3a657f61d7be020d8ead0"],
      "client_ip_address": "203.0.113.24",
      "client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) ...",
      "fbc": "fb.1.1792832531000.IwAR2xExampleClickId",
      "fbp": "fb.1.1792832529000.1234567890"
    },
    "custom_data": { "currency": "USD", "value": 84.00 }
  }]
}

Το hashing μετατρέπει μια διεύθυνση email σε μια σταθερή συμβολοσειρά χαρακτήρων. Η ίδια διεύθυνση δίνει πάντα την ίδια συμβολοσειρά, αλλά η συμβολοσειρά δεν αποκαλύπτει τη διεύθυνση. Η πλατφόρμα χρησιμοποιεί τις τιμές με hash μόνο για να αναζητήσει αντιστοιχία ανάμεσα στους δικούς της χρήστες. Έτσι μπορεί μια αγορά να αντιστοιχιστεί με το άτομο που είδε ή πάτησε τη διαφήμιση, ακόμη κι όταν το πρόγραμμα περιήγησής του μπλόκαρε το pixel.

Πώς λειτουργεί η αφαίρεση διπλοεγγραφών;

Όταν το pixel και ο server στέλνουν και οι δύο την ίδια αγορά, η πλατφόρμα πρέπει να την μετρήσει μία φορά. Και τα δύο αντίγραφα φέρουν το ίδιο όνομα συμβάντος και το ίδιο event id, για παράδειγμα order-1042. Η Meta συγκρίνει το ζεύγος και κρατά ένα αντίγραφο, εφόσον το δεύτερο αντίγραφο φτάσει μέσα σε 48 ώρες από το πρώτο.

Οι περισσότερες περιπτώσεις διπλής καταμέτρησης προέρχονται από δύο αποστολείς που δεν μοιράζονται ID. Μια τυπική περίπτωση είναι η δική της εφαρμογή καταστήματος μιας πλατφόρμας και ένα ξεχωριστό εργαλείο παρακολούθησης που στέλνουν και τα δύο αγορές με τα δικά τους ID. Το άρθρο βοήθειάς μας για την αποφυγή διπλής καταμέτρησης παραθέτει τις συνηθισμένες αιτίες και λύσεις.

Server-side tagging έναντι αποστολής από δεδομένα παραγγελίας

Ο όρος server-side παρακολούθηση χρησιμοποιείται για δύο διαφορετικές ρυθμίσεις. Και οι δύο στέλνουν συμβάντα από έναν server, αλλά ξεκινούν από διαφορετικό σημείο.

Server-side tagging, όπως τα server containers του Google Tag Manager

Με το server-side tagging, το πρόγραμμα περιήγησης στέλνει τα συμβάντα του στον δικό σας server αντί σε κάθε πάροχο ξεχωριστά. Το server container του Google Tag Manager είναι ένα γνωστό παράδειγμα. Τρέχει στο δικό σας Google Cloud project ή σε άλλο περιβάλλον που επιλέγετε. Λαμβάνει αιτήματα από το πρόγραμμα περιήγησης και τα tags του προωθούν τα δεδομένα στο Google Analytics, στη Meta και σε άλλους παρόχους. Εσείς αποφασίζετε ποια δεδομένα πηγαίνουν πού, και ο server μπορεί να τρέχει σε ένα subdomain του site σας.

Τα συμβάντα εξακολουθούν να ξεκινούν από το πρόγραμμα περιήγησης. Αν το tag στο πρόγραμμα περιήγησης μπλοκαριστεί ή η σελίδα ευχαριστίας δεν φορτώσει ποτέ, το server container δεν έχει τίποτα να προωθήσει. Επιπλέον, τον server τον τρέχετε, τον πληρώνετε και τον ενημερώνετε εσείς.

Αποστολή από δεδομένα παραγγελίας

Η δεύτερη προσέγγιση ξεκινά την αγορά από την εγγραφή της παραγγελίας στο κατάστημά σας. Το κατάστημα αναφέρει την πληρωμένη παραγγελία στον server μέσω webhook ή API, και ο server τη στέλνει σε κάθε συνδεδεμένη πλατφόρμα. Το πρόγραμμα περιήγησης χρειάζεται μόνο νωρίτερα, για να αποθηκευτεί το click ID όταν φτάνει ο αγοραστής.

Οι δύο προσεγγίσεις μπορούν να συνδυαστούν. Πολλά καταστήματα συλλέγουν προβολές σελίδας και συμβάντα προσθήκης στο καλάθι στο πρόγραμμα περιήγησης και στέλνουν την αγορά από δεδομένα παραγγελίας. Η αγορά είναι το συμβάν που χρησιμοποιούν οι διαφημιστικές πλατφόρμες για να αναφέρουν το ROAS και να βελτιστοποιούν τις προσφορές, άρα είναι αυτό που χρειάζεται περισσότερο να είναι πλήρες.

Τι διορθώνει η server-side παρακολούθηση και τι δεν διορθώνει;

Η συγκατάθεση εξακολουθεί να ισχύει

Η server-side παρακολούθηση είναι ένας τρόπος παράδοσης δεδομένων, όχι τρόπος να παρακάμψετε τους κανόνες απορρήτου. Όπου ο νόμος απαιτεί συγκατάθεση για cookies μάρκετινγκ ή παρακολούθηση, η απαίτηση αυτή καλύπτει τα δεδομένα που συλλέγετε, όποια διαδρομή κι αν ακολουθήσουν προς την πλατφόρμα. Η μεταφορά ενός tracker στον server σας δεν αλλάζει όσα συμφώνησε ο επισκέπτης.

Η απόδοση παραμένει ανά πλατφόρμα

Κάθε πλατφόρμα εξακολουθεί να αποδίδει τις αγορές με τα δικά της παράθυρα και κανόνες. Τα συμβάντα server δίνουν σε κάθε πλατφόρμα καλύτερα δεδομένα, αλλά τα σύνολα σε Meta, TikTok και Google μπορούν και πάλι να αθροίζουν περισσότερα από τα έσοδα του καταστήματός σας. Για να συγκρίνετε τα κανάλια με ένα ενιαίο σύνολο κανόνων, χρησιμοποιήστε ένα μοντέλο απόδοσης για όλα, όπως τα μοντέλα της απόδοσης στο ROASaurus.

Χρειάζεται το κατάστημά σας server-side παρακολούθηση;

Ένα κατάστημα που διαθέτει σημαντικό προϋπολογισμό σε επί πληρωμή διαφημίσεις στα social ή στην αναζήτηση συνήθως ωφελείται. Η περίπτωση είναι ισχυρότερη όταν ισχύουν αρκετά από τα παρακάτω:

• Η διαφημιστική πλατφόρμα λαμβάνει σαφώς λιγότερα συμβάντα αγοράς από τις παραγγελίες web του καταστήματός σας. Ο οδηγός μας για τους ad blockers και την παρακολούθηση δείχνει πώς να μετρήσετε αυτό το κενό.
• Πολλοί από τους επισκέπτες σας χρησιμοποιούν Safari σε iPhone ή Mac, όπου τα cookies που ορίζονται από scripts διαρκούν το πολύ 7 ημέρες. Δείτε Safari ITP και παρακολούθηση διαφημίσεων.
• Οι αγοραστές συχνά αγοράζουν ημέρες μετά το πρώτο κλικ στη διαφήμιση.
• Η πληρωμή ολοκληρώνεται εκτός του site σας ή οι παραγγελίες πληρώνονται αργότερα, όπως με αντικαταβολή ή τραπεζική μεταφορά.
• Βελτιστοποιείτε τις καμπάνιες για αγορές ή αξία αγορών, οπότε η πλατφόρμα χρειάζεται κάθε πώληση για να μαθαίνει.

Να πώς ένα κενό αλλάζει τις αποφάσεις στην πράξη. Ένα κατάστημα-παράδειγμα έχει 1,000 παραγγελίες web σε έναν μήνα. Το pixel της Meta ανέφερε 820 συμβάντα Purchase, άρα το 18% των παραγγελιών δεν έφτασε ποτέ στη Meta από το πρόγραμμα περιήγησης.

Το ROAS νεκρού σημείου του καταστήματος είναι 2.5 και ο Ads Manager δείχνει ROAS 2.3 με δεδομένα pixel. Με αυτά τα νούμερα οι καμπάνιες χάνουν χρήματα. Αν οι παραγγελίες από διαφημίσεις χάνονταν με τον ίδιο ρυθμό 18%, το πραγματικό ROAS είναι περίπου 2.3 ÷ 0.82 = 2.8, που είναι πάνω από το νεκρό σημείο. Αυτό είναι ανώτερη εκτίμηση, επειδή δεν προήλθε από διαφήμιση κάθε παραγγελία που λείπει. Δείχνει πάντως πώς ένα κενό στην παρακολούθηση μπορεί να κάνει μια κερδοφόρα καμπάνια να φαίνεται ζημιογόνα.

Η server-side παρακολούθηση έχει μικρότερη σημασία για ένα κατάστημα που δεν διαφημίζεται ή που ξοδεύει πολύ λίγα σε διαφημίσεις.

Πώς στέλνει το ROASaurus συμβάντα server-side

Το ROASaurus καταγράφει 19 click ID και έξι πεδία UTM κατά την άφιξη και τα αποθηκεύει με ένα first-party ID επισκέπτη. Στέλνει κάθε αγορά από τις πληρωμένες παραγγελίες του καταστήματός σας στη Meta, στο TikTok, στο Snapchat, στο Pinterest, στο Reddit, στο X, στο Microsoft Ads, στο Taboola, στο LinkedIn, στο OpenAI Ads, στο Spotify, στο AppLovin, στο Criteo, στο AdRoll και στο Outbrain. Στο Shopify, οι μετατροπές του Google Ads στέλνονται από το checkout του Shopify. Τα pixel του προγράμματος περιήγησης μπορούν να τρέχουν παράλληλα με τα συμβάντα server με το ίδιο ID συμβάντος, και οι Meta, TikTok, Snapchat, Pinterest, Reddit, OpenAI Ads, AppLovin και Spotify αφαιρούν τις διπλοεγγραφές. Κάθε αποστολή και η απάντηση της πλατφόρμας παρατίθενται στο Event log.

Διαβάστε περισσότερα στη σελίδα server-side παρακολούθηση ή βρείτε το ηλεκτρονικό σας κατάστημα στη σελίδα ενσωματώσεις.

Πηγές

1. Meta for Developers: Conversions API
2. Meta for Developers: Handling Duplicate Pixel and Conversions API Events
3. Meta for Developers: Customer Information Parameters
4. Google for Developers: An introduction to server-side tagging
5. Google Ads Help: About enhanced conversions

Στο ROASaurus

• Server-side παρακολούθηση στο ROASaurus
• Συγκατάθεση και απόρρητο
• Αποφυγή διπλής καταμέτρησης

Συνεχίστε την ανάγνωση