DEV Community

Cover image for Nylo: Building a Privacy-Minimized Analytics Layer Across Domains You Control
Ravi Teja Surampudi
Ravi Teja Surampudi

Posted on

Nylo: Building a Privacy-Minimized Analytics Layer Across Domains You Control

Most organizations do not operate a single website.

A typical customer journey might move through:

company.com
    ↓
docs.company.com
    ↓
company-academy.com
    ↓
company-checkout.com
Enter fullscreen mode Exit fullscreen mode

These properties may belong to the same organization, but browsers and analytics systems can treat each domain as a separate visitor and session.

Cross-domain measurement is possible with major analytics platforms, but it normally ties the implementation to a specific vendor, transfers an existing measurement identifier through the destination URL, or depends on users authenticating.

I built Nylo to explore another approach:

Preserve pseudonymous continuity across domains an organization controls, without browser fingerprinting, third-party cookies, or requiring the visitor to log in.

Nylo is not intended to identify a person. It is intended to answer a narrower question:

Did the same pseudonymous browser journey continue from one authorized domain to another?

What Nylo is

Nylo consists of:

  • A zero-dependency JavaScript client SDK
  • A server-side event ingestion interface
  • A pseudonymous identifier called a WaiTag
  • A short-lived cross-domain token exchange
  • DNS-based verification of participating domains
  • Configurable event collection
  • Storage adapters for different backend systems

The core analytics SDK is available under the MIT License. Production commercial use of the cross-domain WTX-1 functionality uses a separate commercial license.

Nylo is designed to function as an analytics collection and continuity layer. It can eventually send events to an existing warehouse or analytics platform rather than requiring organizations to replace their reporting stack.

How continuity works

Consider a visitor moving between two independently registered domains:

Visitor opens site-a.com
          |
          v
Nylo creates a pseudonymous WaiTag
          |
          v
Visitor follows an authorized link
          |
          v
A short-lived token is transferred
          |
          v
site-b.com verifies the token
          |
          v
Both events reference the same
pseudonymous journey
Enter fullscreen mode Exit fullscreen mode

Before enabling cross-domain continuity, the participating domains must be authorized.

Nylo uses DNS TXT verification so that an organization must demonstrate control of a domain before it can participate in the exchange.

This prevents an arbitrary website from adding the SDK and joining another organization's analytics namespace.

What a WaiTag contains

A WaiTag is generated using cryptographically secure randomness and domain-related context.

It is not generated from:

  • An email address
  • A phone number
  • A name
  • An IP address
  • Canvas characteristics
  • Fonts
  • WebGL output
  • A device fingerprint

The server does not require a mapping between the WaiTag and a known individual.

That distinction is important: Nylo attempts to preserve journey continuity, not establish real-world identity.

Basic integration

The browser integration starts with a script tag:

<script
  src="https://analytics.example.com/nylo.js"
  data-customer-id="1"
  async>
</script>

Applications can record explicit events:

Nylo.track("signup_click", {
  plan: "professional"
});
Enter fullscreen mode Exit fullscreen mode

Nylo.trackConversion("purchase", 49.99);

The current session state can also be inspected:

const session = Nylo.getSession();

console.log(session);

Enter fullscreen mode Exit fullscreen mode

A server implementation supplies the persistence layer:

interface NyloStorage {
  createInteraction(data: unknown): Promise<unknown>;
  getCustomer(id: number): Promise<unknown>;
  getCustomerByApiKey(apiKey: string): Promise<unknown>;

  parseDomain(
    domain: string
  ): {
    mainDomain: string;
    subdomain: string | null;
  };

  getDomainVerification(
    domain: string,
    customerId: number
  ): Promise<unknown | null>;

  isDomainVerified(
    domain: string,
    customerId: number
  ): Promise<boolean>;
}
Enter fullscreen mode Exit fullscreen mode

This keeps Nylo independent of a particular database or warehouse.

Where Nylo could be useful

Nylo is primarily intended for organizations with several related web properties, such as:

  • SaaS journeys
  • Marketing site → Documentation → Academy → Product signup
  • Multi-brand portfolios
  • Parent company → Product brand → Shared commerce property
  • Self-hosted analytics environments

Organizations that want to control the collection server, storage system, retention policy, and downstream destinations.

Anonymous journey analysis

Situations where authentication is unavailable or unnecessary, but aggregate and pseudonymous journey continuity remains useful.

Where Nylo should not be used

Nylo is not designed to:

  • Track people across unrelated organizations
  • Create an advertising identity graph
  • Replace a consent-management platform
  • Circumvent browser privacy controls
  • Infer a person's identity
  • Guarantee regulatory compliance
  • Replace a complete analytics reporting platform

It should only connect domains that have been explicitly authorized and legitimately participate in the same measurement environment.

Pseudonymous does not mean anonymous

This is one of the most important architectural boundaries.

A pseudonymous identifier may still fall within privacy and data-protection requirements, particularly when it is persistent or combined with behavioral information.

Nylo minimizes the information used for continuity, but it does not eliminate an organization's obligations around:

  • Transparency
  • Consent where required
  • Data retention
  • User deletion
  • Access controls
  • Purpose limitation
  • Security
  • Regional privacy laws

The optional identify() API also needs to be treated separately. Associating a WaiTag with an account or customer identifier changes the privacy characteristics of the deployment.

Nylo should be evaluated as a privacy-minimizing technology, not as a privacy or consent bypass.

Current project status

The repository currently includes:

  • The browser SDK
  • Express server integration
  • DNS verification
  • SQLite and PostgreSQL examples
  • Input validation and security utilities
  • An interactive local demonstration
  • MIT and commercial licensing documentation
  • A security disclosure policy

The next engineering priorities are:

  • Automated browser and server test coverage
  • A hosted two-domain demonstration
  • A published package and tagged releases
  • Independent security review
  • Compatibility testing across browser privacy modes
  • Destination adapters for existing analytics platforms
  • Clear consent and retention integration guidance

Try it locally
git clone https://github.com/tejasgit/nylo.git
cd nylo/examples
npm install
npm start

Then open:

http://localhost:5000/demo.html

The repository is available at:

GitHub logo tejasgit / nylo

Privacy-first cross-domain analytics. No cookies. No login. No PII.

Nylo
Privacy-first cross-domain analytics. No third party cookies. No login. No PII

MIT License Zero dependencies SDK size


Google killed third-party cookies. Your cross-domain analytics broke. The industry says you have two options: force users to log in (UID 2.0, LiveRamp) or lose individual-level data (Google Topics API).

Nylo is a third option. It tracks user behavior across your domains using pseudonymous identifiers that never resolve to personal information. No third party cookies, no fingerprinting, no PII. Individual-level resolution without knowing who anyone is.

What Nylo Is / Is Not



































Is Pseudonymous continuity across domains without login or PII
Is A zero-dependency client SDK (~12KB) with server-side event ingestion
Is Privacy-by-design: all 23 tracking features default to off
Is not Fingerprinting users (no canvas, font, WebGL, or device fingerprints)
Is not Storing IP addresses or resolving identity to a person
Is not A replacement for consent — it reduces the need for it
Works best when





I am specifically looking for feedback from:

  • Browser security engineers
  • Privacy engineers
  • Analytics implementation specialists
  • JavaScript SDK maintainers
  • Developers operating multiple related domains

Useful feedback would include concrete attack scenarios, browser compatibility failures, API design concerns, and examples of real cross-domain journeys that current analytics tools handle poorly.

Top comments (0)