Device Recognition

Device recognition is a server-side mechanism for re-identifying returning visitors when traditional identifiers (cookies, localStorage) have been cleared or are unavailable. It uses a combination of HTTP request signals and optional browser attributes to generate a probabilistic device hash — without relying on browser fingerprinting libraries or third-party scripts.

The Problem

The _dfid cookie provides persistent first-party identity, but it can be lost:

• The visitor clears their browser cookies or browsing data
• The visitor uses private/incognito browsing
• Safari ITP clears storage in edge cases
• The visitor switches to a different browser profile

When the cookie is gone, the Ingestion Gateway generates a new _dfid, and all previously collected vendor IDs, click IDs, and identity associations are orphaned in Redis under the old anonymous ID. The visitor appears as a brand new user.

Device recognition provides a probabilistic recovery path: if the incoming request’s device signals match a previously seen device, Signal can reconnect the visitor to their existing identity record.

How It Works

Signal Collection

When a request arrives at the Ingestion Gateway, the following signals are collected:

Server-side signals (always available):
  → IP address
  → User-Agent header
  → Accept-Language header

Client-side signals (sent by Datafly.js when enabled):
  → Screen resolution (e.g. "1920x1080")
  → Timezone (e.g. "Europe/London")
  → Locale (e.g. "en-GB")

Optional signals (opt-in only):
  → WebGL renderer string
  → Canvas hash

Hash Generation

The collected signals are concatenated and hashed using SHA-256 to produce a device fingerprint:

Input:   IP + User-Agent + Accept-Language + screen + timezone + locale
Hash:    SHA-256(concatenated input)
Result:  "a3f8c2e1b9d7..." (64-character hex string)

The hash is stored in Redis, keyed to the visitor’s current _dfid:

SET device:{hash} {anonymous_id} EX {ttl_seconds}

Identity Recovery

On subsequent requests where no _dfid cookie is present, the gateway computes the device hash from the incoming signals and checks Redis:

1. New request arrives -- no _dfid cookie
2. Compute device hash from request signals
3. GET device:{hash} from Redis
4. If found → existing anonymous_id recovered
5. Set _dfid cookie to the recovered anonymous_id
6. All previous identity associations are restored

Confidence Scoring

Not all signal combinations are equally reliable. Device recognition assigns a confidence score based on which signals matched and how unique the combination is:

The confidence score is returned in the event payload so that downstream consumers can decide how to treat the match:

{
  "anonymous_id": "f47ac10b-58cc-4372-a567-0d02b2c3d479",
  "device_recognition": {
    "matched": true,
    "confidence": 0.92,
    "level": "high",
    "signals_matched": ["ip", "user_agent", "accept_language", "screen", "timezone", "locale"]
  }
}

Configuration

Device recognition is configured per organisation in the Management UI or via the Management API:

{
  "device_recognition": {
    "enabled": true,
    "ttl_days": 30,
    "confidence_threshold": 0.7,
    "optional_signals": {
      "webgl": false,
      "canvas": false
    }
  }
}

Publisher Paywall Integration

For publishers using device recognition to enforce metered paywalls (detecting returning visitors who have cleared cookies to reset their article count), Signal exposes a dedicated API endpoint:

POST /v1/fingerprint/check
Content-Type: application/json
Authorization: Bearer {api_key}

{
  "signals": {
    "ip": "203.0.113.42",
    "user_agent": "Mozilla/5.0 ...",
    "accept_language": "en-GB,en;q=0.9",
    "screen": "1920x1080",
    "timezone": "Europe/London",
    "locale": "en-GB"
  }
}

Response:

{
  "matched": true,
  "anonymous_id": "f47ac10b-58cc-4372-a567-0d02b2c3d479",
  "confidence": 0.92,
  "level": "high",
  "first_seen": "2026-02-01T10:30:00Z",
  "visit_count": 47
}

This allows the publisher’s paywall logic to query Signal directly and determine whether the visitor has been seen before, regardless of cookie state.

Privacy Considerations

Device recognition is designed with privacy in mind:

• Opt-in only — disabled by default; must be explicitly enabled per organisation
• Hashed signals — raw signals are never stored; only the SHA-256 hash is persisted in Redis
• Configurable TTL — device hashes expire after the configured TTL (default 30 days, max 90 days)
• No third-party sharing — device hashes are used only within the customer’s own Signal deployment
• GDPR considerations — device hashes may constitute personal data under GDPR. Customers should include device recognition in their privacy policy and cookie consent mechanism. The hash can be deleted via the Management API as part of a data subject access request (DSAR)

Limitations

Device recognition has inherent limitations that affect its accuracy:

Despite these limitations, device recognition provides meaningful identity recovery for the majority of desktop browser sessions where cookies have been cleared — the most common identity loss scenario.