Netlify

Netlify Log Drains stream a site's traffic logs to an HTTP endpoint in near real time. Point one at POST /v1/logs/netlify and every page request Netlify served becomes a pageview, with no script on the page and no change to your site.

Log drains are a paid Netlify feature (Enterprise, or the Netlify Analytics / Log Drains add-on, depending on your plan).

Create a source of kind logs for the site in the dashboard to get an ingest token (in_…).

Set up the drain

1. Netlify → your site → Site configuration → Log drains → Add log drain.
2. Service: General HTTP endpoint.
3. Log type: Traffic. (Function and edge-function logs may share the same drain; they are skipped server-side.)
4. Endpoint URL: https://api.example.com/v1/logs/netlify
5. Format: JSON or NDJSON; both are accepted.
6. Authorization header: Bearer in_…

Netlify's UI also allows API keys as query parameters, and every /v1/logs/* endpoint accepts the ingest token that way:

https://api.example.com/v1/logs/netlify?token=in_...

Use the Authorization field when you can: a token in a URL is visible to anyone who can read the site's settings, and is easier to leak into logs.

What becomes a pageview

An entry counts when all of the following hold:

• it is a traffic log (log_type is traffic or absent);
• the method is GET or HEAD;
• the path is not an asset path (same extension and prefix rules as every other source; see Access logs);
• the status is not a 3xx redirect.

Everything else is counted in the response's skipped figure, not rejected.

Fields map like this:

If you turn on Netlify's option to exclude PII, user_agent and client_ip are omitted from the logs. Ingest still works, but visitors can no longer be told apart, and device/browser/country reporting goes empty, so leave the option off if you want visitor counts. MetrikStack never stores the IP itself (see Privacy & data retention).

Drains and the request-id merge

Netlify's request_id is the platform's own id, unrelated to the X-MetrikStack-Request-Id that the Node SDK sets, and a drain entry carries none of your application's response headers, so the two cannot be matched. Run the drain as the site's only source and every traffic line is a pageview; run it next to the tracker script and merging falls back to the 2 s dedupe window on (site, visitor, path).

A drain is the better source for cached and bot traffic, which never reaches a browser script; the script is the better source for screen size, language and time on page. Running both is reasonable; just expect the fallback window, not exact request-level merging.

Response

{ "accepted": 42, "skipped": 118, "rejected": [] }