Native Server-Side Tracking: GA4 vs Adobe vs Matomo

Introduction

When we talk about server-side tracking, most people think of server-side tag managers like GTM SS or Adobe Edge. But you don’t necessarily need a TMS — it’s totally possible to send direct server-to-vendor HTTP calls using basic POST or GET requests.

Let’s compare how it works across 3 key platforms: Google Analytics 4, Adobe Analytics, and Matomo.

🟢 Google Analytics 4 – Measurement Protocol v2

GA4 provides a dedicated server-side endpoint to send events directly.

• Endpoint:
  POST https://www.google-analytics.com/mp/collect
• Required parameters: ParamDescriptionclient_idUnique client ID (from the _ga cookie)user_idOptional user ID for signed-in userseventsArray of events with name + paramstimestamp_microsOptional microsecond timestamp
• Key point:
  Make sure to extract client_id from the frontend (cookie or localStorage) and send it alongside your server event. Otherwise, GA4 won’t link it to the session properly.
• Use cases:
  Backend transactions, confirmation emails, or pure back-office actions (e.g. ERP updates).

---

🔵 Adobe Analytics – Direct HTTP Tracking

Adobe also allows direct HTTP requests, although it’s slightly more legacy in format.

• Endpoint:
  GET or POST to:
  https://<trackingServer>.omtrdc.net/b/ss/<reportSuite>/0/
• Required parameters: ParamDescriptionvidVisitor ID (manually generated or passed from ECID)midOptional Experience Cloud ID (ECID)pageNamePage name or hit labeleventsEvent string, e.g. purchaseproductsProduct string in Adobe format
• Key point:
  Adobe’s visitor reconciliation depends on a properly managed vid or ECID. Ideally, the ECID is set client-side and passed to the backend.
• Use cases:
  Hybrid setups with web + native apps, loyalty actions, post-login behaviors tracked server-side.

---

🟠 Matomo – Tracking API (Simple & Flexible)

Matomo provides a very flexible HTTP API with both GET and POST options.

• Endpoint:
  https://matomo.example.com/matomo.php
• Required parameters: ParamDescriptionidsiteMatomo site IDcidVisitor ID (manually generated UUID)uidOptional user IDe_cEvent categorye_aEvent actione_nEvent namee_vEvent value (optional)urlPage URL associated with the event
• Key point:
  Like GA4, you should extract a visitor ID (cid) on the frontend and propagate it server-side to preserve continuity.
• Use cases:
  GDPR-friendly tracking, self-hosted analytics, and advanced control use cases.

---

🎯 Best Practices for Native Server-Side Tracking

✅ Always pass a persistent identifier:

• client_id for GA4
• vid or mid for Adobe
• cid or uid for Matomo

✅ Sync that ID from your frontend:

• Read it from a cookie, localStorage, or via header injection

✅ Add timestamps if possible:

• To preserve event ordering, especially when logging backend actions asynchronously

✅ Log and document:

• Keep a copy of what you’re sending (for debug + compliance)

---

✅ When to use native server-side tracking?

‣ You’re working on backend-driven logic (e.g. payment confirmation, account creation)
‣ You need full control over what’s sent
‣ You want to avoid client JS execution (privacy, ad blockers, security)
‣ You’re building fraud detection, reconciliation, or scoring mechanisms
‣ You’re looking for a lightweight alternative to full server-side TMS infrastructures