Skip to main content
After Signal activation, the One-screen serving setup checks your hosting stack and produces one copy-ready configuration. You do not need to compare installation methods yourself. PlainRouter uses the same managed collector, consent rules, and event contract for both serving paths. Only the route from your website to the collector changes.

​
How PlainRouter selects a path

Path A sends collection traffic through your PlainRouter-managed subdomain. Path B transparently forwards a route on your website to the same collector. Path B does not run PlainRouter code in your hosting account and does not change which visitors are eligible for measurement.
Path A is the default and remains fully supported. Path B gives supported stacks a true same-origin route for consented, server-issued browser identifiers. Both paths apply the same consent gate.

​
Generate your setup

1

Open the serving setup

Complete DNS validation and Signal ingestion verification, then open Signals.
2

Let PlainRouter check your hosting stack

PlainRouter checks bounded DNS and response-header evidence in the background. While the check is running, the page shows Pending and refreshes the stored result automatically.If the stack cannot be determined, answer Where is your website hosted? with the exact provider or server, then click Detect hosting.
3

Copy the generated block

PlainRouter shows one block for the detected stack. For Path B, click Activate Path B first, then Copy code and add the complete block to your hosting configuration. Do not edit its generated prefix, destination, or secret.For Path A, keep the displayed CNAME in place. PlainRouter manages the collector and HTTPS certificate behind it.
4

Verify the live path

Deploy the hosting change and load your live website. The First arrival check turns green after PlainRouter stores the first valid arrival.For Path B, also click Run verification. The side-effect-free forwarding probe checks the deployed route without creating an event or arrival. Path B turns green only after both the probe passes and an authenticated arrival is observed.
Path A’s first successful arrival verification remains latched after recent activity ages out. It does not return to an unverified setup state merely because no new arrival appears in the recent window.

​
Path B forwarding requirements

Install the entire generated block. Transparent forwarding must preserve:
  • The original host and visitor path.
  • Cookie and Set-Cookie in both directions.
  • Sec-Fetch-* and Accept request headers.
If your platform strips the fetch metadata, PlainRouter cannot classify the document request. It writes no arrival for that request and increments only the aggregate undetermined counter.
Path B’s generated destination contains a low-privilege forwarding secret. Only members with workspace management permission can view or copy it. Do not publish it in documentation, logs, or a public repository.

​
Exact site domains

Credentialed browser collection requires at least one exact HTTPS site domain in your Signal configuration. Wildcards remain available for their existing matching behavior, but they do not grant credentialed CORS coverage. Add the apex domain explicitly when you need apex coverage.

​
Rotate a Path B secret

Click Rotate forwarding secret, copy the newly generated block, and deploy it. PlainRouter accepts both the old and new secret during the transition. The overlap ends when PlainRouter successfully ingests the first authenticated arrival using the new secret or when you click Confirm new secret installed. A malformed or failed request does not acknowledge the new secret or end the overlap. Keep the old deployment available until one of those conditions is met. The side-effect-free forwarding probe attests only the currently active secret. A probe signed with the pending overlap secret cannot mark the path verified or complete rotation. If tracker key storage is temporarily unavailable, the probe fails closed with a retryable response instead of recording a pass.

​
Understand detection and verification states

Retry detection and Retry verification start fresh background checks. DNS and forwarding probes never run inside the page request.

​
Troubleshoot

Enter the exact hosting provider or server name. PlainRouter uses that declaration when DNS and response headers are unavailable. If the answer is not recognized, confirm the public site domain and retry when the site is reachable.
The probe reached your site but did not observe the expected forwarding response. Reinstall the complete generated block and confirm that no proxy, middleware, or transform removes the original path, cookies, Sec-Fetch-*, or Accept headers.
Open the live website through the exact configured domain. Invalid or unauthenticated traffic does not complete the arrival check.
A member with workspace management permission can click Revert to Path A. Keep the validated CNAME in place before reverting.