Server-side tracking, without the pitch.
Three different things get sold under this name and they solve different problems. Here is what each one actually does, which parts of it mrkr ships, and which parts it deliberately does not.
In short
What is server-side tracking?
Server-side tracking moves part of analytics collection off the visitor's browser and onto a server. It survives content blockers and browser storage limits because the request is first-party and the processing is yours. It cannot see anything that only exists in the browser, so in practice it complements a client tracker rather than replacing one.
The confusion is that the term covers three setups with different costs and different failure modes. Separating them is most of the work, so this page does that first and only then says what mrkr does.
Compared
The three things people mean. Same phrase, three architectures. The right one depends on whether your problem is delivery, distribution, or events that never touch a browser at all.
| Feature | First-party proxy | Server-side tag manager | Backend event API |
|---|---|---|---|
| What it is | The tracker and ingest served from your own subdomain | A container you host that receives events and forwards them to vendors | Your backend posts events straight to a vendor endpoint |
| Solves | Blocked requests | Fan-out to ad platforms, payload control | Events with no browser: webhooks, jobs, payments |
| Sees browser behaviour | The tracker still runs | Only what you forward to it | No |
| Infrastructure you run | None with a managed proxy | A container and its hosting bill | Your own queue and retries |
| Typical cost | Included | Hosting plus engineering time | Engineering time |
| mrkr ships it | Managed | No | No, and it is not a supported path |
What mrkr does on the server.
A managed first-party proxy
One CNAME, and the tracker and ingest are served from your own subdomain over a certificate mrkr provisions.
A server-side crawler beacon
/api/data/crawl records the AI and search bots that fetch raw HTML and never execute your JavaScript.
Nothing for you to host
No container, no certificate to renew. The crawler catalogue updates server side without you redeploying.
The part a server cannot see.
A backend knows a request happened. It does not know whether anyone read the page, how far they scrolled, how long they stayed engaged, where the layout shifted under their thumb, or what they clicked before they gave up.
That is why mrkr keeps a browser tracker and makes it undetectable-by-filter rather than replacing it with server logs. Sources, campaigns and revenue are only half of what you need. The other half only exists on the client.
What mrkr does not do.
It is not a server-side tag manager
No container, no tag templates, no fan-out to Meta CAPI, Google Ads or TikTok Events. Run one alongside mrkr instead.
There is no backend event API
Ingest requires a browser-shaped request. A POST from a script or curl fails those checks and is discarded as a bot.
No API key, no backend contract
Backend ingestion is not supported, so there is nothing to authenticate with and no promise the payload shape stays put.
It does not replace your warehouse
mrkr stores pre-aggregated counters, not a raw event stream. There is no self-serve export or query API; ask and we will pull your data out.
Live demo
Watch it arrive. The live demo shows the realtime view on real demo traffic. Same ingest path the proxy uses, same five-minute live window.
Open the live demoFAQ
What is server-side tracking?
Collection that happens on a server rather than entirely in the visitor's browser. In practice the phrase covers three different setups: proxying a client-side tracker through your own domain, running a server-side tag manager that receives events and fans them out to vendors, and sending events straight from your backend through a vendor API.
Is server-side tracking more accurate than client-side?
For delivery, yes. Requests from your own domain are not cancelled by content blockers and are not affected by browser storage limits. For behaviour, no. A server never sees engaged time, rage clicks, layout shift or a session recording, because none of those exist outside the browser.
Does mrkr support server-side tracking?
Partly, and it is worth being exact. mrkr ships a managed first-party proxy that serves the tracker and ingest from your own subdomain, and a server-side crawler beacon that records AI and search bots your JavaScript never sees. mrkr is not a server-side tag manager and does not offer a supported backend event API.
Can I POST events to mrkr from my backend?
No. The ingest endpoint is built to receive a genuine browser beacon: it checks the Origin header, the Sec-Fetch-Site header and the shape of the User-Agent, and a plain POST from a server fails those checks and is discarded as a bot. There is no API key and no stable backend contract, so anything built that way would break silently.
Can mrkr attribute revenue that lands in a webhook later?
For Stripe, yes. Connect Stripe and its signed webhook delivers paid charges and Checkout Sessions to mrkr, which credits each one to the visit that started it, even when the payment confirms after the visit ended. Other processors report revenue with a purchase event from the page.
Is server-side tracking GDPR compliant?
Moving collection to your server changes who handles the data, not whether you needed consent. If you store or read something on the visitor's device, the ePrivacy rule still applies. mrkr is cookieless by default, which is what removes the banner, and that is true on the proxy and off it.
Do I need a server-side tag manager?
If you are fanning one event out to several ad platforms with conversion APIs, that is exactly what a server-side tag manager is for, and mrkr is not one. If what you want is analytics that is not blocked, a first-party proxy solves that on its own without the container, the hosting bill, or the second system to debug.
Start with one line of HTML.Your first visitors show up within a minute.