Finding reference

Identifier-like values observed across domains

Retained outbound request evidence showed identifier-like keys or values moving to a different domain or third-party context within the observed scan scope. Review the evidence context, methodology, common causes, and reviewer questions for this CertScore finding.

Selected finding

Identifier-like values observed across domains

HighReview Signal evidenceDirect observationThird-party trackingSeen on ~2% of scanned top sites

Benchmark frequency is directional market context only. It is not a compliance benchmark, legal conclusion, or severity score. Rare findings may be top-ranked only when retained evidence is strong; common findings may remain medium when evidence is automated or context-dependent. Rarity is not severity, and prevalence is not compliance risk.

Observed

Retained outbound request evidence showed identifier-like keys or values moving to a different domain or third-party context within the observed scan scope.

Why this matters

Identifier-like values in cross-domain requests can be relevant to tracking, attribution, advertising, analytics, identity, and vendor-governance review. For review teams, this signal can help identify where browser-visible data flows may warrant review for purpose, consent state, disclosure, contract, minimization, and vendor-governance context.

Detection methodology

CertScore inspects retained outbound request evidence for identifier-like keys, redacted values, destination domains, request origin/path, third-party context, vendor/category classification, timing, and consent context where available. This finding is surfaced when retained evidence shows identifier-like data in an outbound request to a different domain or third-party context within the observed scan scope. CertScore treats cross-domain identifier-sharing evidence as a review signal. The scanner does not determine personal identity, identity resolution, legal status, consent validity, sale/share status, or compliance status. Reviewers should consider whether the value is pseudonymous, hashed, scoped, session-only, security-related, analytics-related, advertising-related, or otherwise necessary, and whether the retained evidence is sufficient for the intended review.

Confidence semantics: Good when retained outbound request evidence includes request origin and path, destination domain, identifier-like key or redacted value pattern, timing, vendor or category classification, and enough context for reviewer inspection; stronger when retained evidence also includes repeated examples, consent timing, source and destination context, stable runtime anchors, and usable coverage. Manual review is still needed for purpose, identifier scope, identity-resolution risk, consent state, server-side behavior, and remediation quality.

Top-finding calibrationWhat must be retained to surface, top-rank, demote, or suppress this finding.

Minimum to surface

  • Identifier-like key/value pattern in outbound cross-domain request.

High confidence requires

  • Source/destination plus redacted key and vendor/category.

Top ranking requires

  • Persistent or scoped identifier to adtech/identity destination or pre-consent/post-reject timing.

Demote or suppress when

  • Generic query key.
  • Destination unknown.
  • Unredacted identifiers.

These rules describe ranking calibration for already-projected findings. They do not create findings from raw signals.

Example evidence

Cross-domain identifier request example

  • artifact=req_004
  • role=finding_supporting_artifact
  • url=https://example.com/
  • initiator_origin=https://example.com
  • destination_origin=https://measure.example
  • request_path=/collect [query_redacted=true]
  • third_party_context=true
  • identifier_like_keys=client_id, campaign_id [values_redacted=true]
  • timestamp_ms=3180
  • vendor_category=analytics_or_ad_measurement
  • review_caveat=manual review should confirm purpose, identifier scope, consent timing, destination role, and whether the value is pseudonymous, scoped, hashed, or otherwise limited

Review context

  • possible_flow=analytics_attribution_or_ad_measurement
  • source_domain=example.com
  • destination_domain=measure.example
  • identifier_values_redacted=true
  • consent_timing_context=manual_review_recommended
  • manual_review_needed=true

What should not count by itself

  • third_party_request_present=true [insufficient_without_identifier_signal]
  • vendor=Example Measurement [insufficient_without_request_anchor]
  • cookie_present=true [audit_only_without_outbound_transfer]
  • query_key=id [insufficient_without_origin_destination_context]
View redacted sample JSON
Redacted sample JSON
{
  "findingId": "cross_domain_identifier_sharing_observed",
  "label": "Identifier-like values observed across domains",
  "category": "Third-party tracking",
  "criticality": "high",
  "evidenceConfidence": "review_signal",
  "directVsInferred": "direct_observation",
  "evidence": {
    "summary": "Retained outbound request evidence showed identifier-like keys or values moving to a different domain or third-party context within the observed scan scope.",
    "examples": [
      {
        "title": "Cross-domain identifier request example",
        "lines": [
          "artifact=req_004",
          "role=finding_supporting_artifact",
          "url=https://example.com/",
          "initiator_origin=https://example.com",
          "destination_origin=https://measure.example",
          "request_path=/collect [query_redacted=true]",
          "third_party_context=true",
          "identifier_like_keys=client_id, campaign_id [values_redacted=true]",
          "timestamp_ms=3180",
          "vendor_category=analytics_or_ad_measurement",
          "review_caveat=manual review should confirm purpose, identifier scope, consent timing, destination role, and whether the value is pseudonymous, scoped, hashed, or otherwise limited"
        ]
      },
      {
        "title": "Review context",
        "lines": [
          "possible_flow=analytics_attribution_or_ad_measurement",
          "source_domain=example.com",
          "destination_domain=measure.example",
          "identifier_values_redacted=true",
          "consent_timing_context=manual_review_recommended",
          "manual_review_needed=true"
        ]
      },
      {
        "title": "What should not count by itself",
        "lines": [
          "third_party_request_present=true [insufficient_without_identifier_signal]",
          "vendor=Example Measurement [insufficient_without_request_anchor]",
          "cookie_present=true [audit_only_without_outbound_transfer]",
          "query_key=id [insufficient_without_origin_destination_context]"
        ]
      }
    ]
  }
}

Regulatory review context

Cross-domain identifier sharing review

Retained outbound request evidence showed identifier-like cross-domain request patterns that may be relevant to tracking, advertising, analytics, attribution, consent, transparency, sale/share, and vendor-governance review. Applicability depends on identifier scope, purpose, destination role, consent state, jurisdiction, server-side behavior, and manual review.

GDPR online identifier reviewGDPR transparency and third-party disclosure reviewePrivacy cookie/device identifier reviewEU GDPR/ePrivacy identifier sharing reviewCCPA/CPRA sale/share and cross-context behavioral advertising reviewFTC privacy representation review
View applicability notes

Legal and regulatory frameworks

  • GDPR online identifier reviewCookie IDs, IP addresses, device IDs, or other online identifiers may require review where they could relate to an identified or identifiable person.
  • GDPR transparency and third-party disclosure reviewRetained evidence suggests identifiers may move to third-party analytics, advertising, attribution, or identity partners.
  • ePrivacy cookie/device identifier reviewIdentifier-sharing review may be relevant where cookies, browser storage, redirects, or terminal-equipment information are involved.

Jurisdictional contexts

  • EU GDPR/ePrivacy identifier sharing reviewEU/EEA users, online identifiers, profiling, cookies, or third-party sharing may be in scope depending on purpose, consent state, jurisdictional context, and manual review.
  • CCPA/CPRA sale/share and cross-context behavioral advertising reviewCalifornia users and identifier-like request signals may be relevant to advertising, identity matching, attribution, sale/share, or cross-context behavioral advertising review depending on purpose, vendor role, user region, and manual review.
  • FTC privacy representation reviewRuntime sharing may conflict with privacy disclosures, consent promises, or data-sharing statements.

This finding does not determine legal status, personal identity, identity resolution, sale/share status, consent validity, or compliance status. Review the retained request anchors, redacted identifier-like keys, source and destination context, vendor purpose, consent timing, regional configuration, and applicable exemptions.

Evidence standard

Strong

  • Retained outbound request evidence includes origin and path, destination domain, timestamp, and redacted identifier-like key or value pattern.
  • Evidence shows the destination is a different domain or third-party context.
  • Evidence includes vendor or category classification, purpose context, or request pattern sufficient for reviewer inspection.
  • Evidence redacts or omits full identifier values, query strings, and payloads.
  • Coverage context indicates request ordering and retained anchors were not materially blocked or unreliable.

Good

  • Retained request evidence shows identifier-like data sent cross-domain, but purpose, identifier scope, or vendor classification is less complete.
  • The retained example is enough for a reviewer to inspect origin and path, destination, redacted key or value, and timing manually.
  • The evidence is likely a cross-domain identifier-sharing review signal, but identity-resolution risk, consent relevance, server-side behavior, and legal significance require manual review.

Audit-only

  • Third-party request observed, but no identifier-like key or value pattern is retained.
  • Identifier-like key appears in a request, but destination, timing, or context is incomplete.
  • Vendor registry or policy text suggests sharing, but no retained outbound request artifact supports the observed state.

Insufficient

  • Third-party request alone.
  • Vendor name alone.
  • Generic query string without identifier-like signal.
  • Cookie presence without evidence of outbound cross-domain transfer.
  • Identifier-like key without request origin, path, and destination context.
  • Unredacted identifier values in public examples.
  • Claims about personal identity, identity graph, legal status, sale or share status, compliance status, or tracking lawfulness based only on automated evidence.

Evidence levels explain how CertScore treats retained runtime artifacts. They are not legal conclusions.

Common causes

  • Analytics or advertising requests include client, session, campaign, or device identifiers.
  • Attribution or measurement SDKs append persistent IDs to outbound requests.
  • Identity, data platform, or tag-manager integrations pass pseudonymous IDs across domains.
  • Redirect or pixel flows include identifier-like parameters.
  • Consent, regional, or minimization settings do not suppress identifier-like parameters before transmission.

Recommended review questions

  • Which outbound request carried the identifier-like key or value?
  • What was the source origin and destination origin?
  • Which query keys or parameter names were retained, and were values redacted or hashed?
  • Is the value likely session-scoped, client-scoped, device-scoped, campaign-scoped, hashed, pseudonymous, or otherwise limited?
  • What vendor/category or endpoint purpose is associated with the destination?
  • Did the request occur before consent, after consent, after reject, or outside known consent context?
  • Could the value support analytics, attribution, fraud prevention, security, advertising, or another purpose?
  • Is the behavior browser-visible only, or might relevant server-side sharing be outside scan scope?
  • Are query strings, identifiers, cookie values, and payloads redacted while preserving stable anchors?

Limitations and cautions

  • This finding is an automated cross-domain identifier-sharing review signal, not a legal conclusion, certification, compliance determination, sale/share determination, or determination of tracking lawfulness.
  • Automated request evidence can identify identifier-like keys or value patterns, but it does not determine personal identity, identity resolution, or a complete identity graph.
  • Identifier-like values may be pseudonymous, scoped, hashed, session-only, campaign-related, security-related, or otherwise limited.
  • Some cross-domain requests may support analytics, attribution, fraud prevention, security, service delivery, or other context-dependent purposes.
  • Server-side sharing, partner-side processing, and downstream data use may not be visible to a browser scan.
  • Consent timing, jurisdiction, vendor purpose, and applicable exemptions require manual review.
  • CertScore redacts or avoids retaining full query strings, identifiers, cookie values, and sensitive payloads while preserving stable anchors needed for review.
  • Automated findings may contain errors and should be reviewed with the retained evidence.
  • Not detected means not observed in the scan scope; it is not proof of absence.
  • Findings are runtime evidence and public-surface observations for review, not legal conclusions.

Related reading

Reference notes

  • CertScore uses findings, evidence, signals, and observations consistently: signals are raw runtime or page-surface events, evidence is retained support, observations are interpreted evidence context, and findings are promoted review items.
  • Findings are runtime evidence and public-surface observations for review. Observed signals may surface possible concerns, but review is recommended before operational or legal reliance.
  • Finding reference content is reviewed periodically and updated when material guidance changes. CertScore monitors guidance families such as EDPB consent and ePrivacy materials, ICO cookie guidance, CNIL tracker recommendations, FTC privacy and dark-pattern materials, and relevant accessibility guidance where applicable.
  • EDPB consent guidance is relevant to consent quality and affirmative indication where consent is relied upon.
  • EU ePrivacy cookie/tracker principles are relevant to storing information or gaining access to information on user terminal equipment.
  • ICO cookie and similar technologies guidance is relevant to active consent, clear explanation, and essential-cookie exceptions.
  • CNIL cookie/tracker and analytics guidance is relevant to tracker consent and limited analytics exemptions.
  • FTC dark-pattern and commercial-surveillance materials may be relevant to hidden tracking or unclear user-choice review, but this finding does not determine deception, unfairness, or legal status.
  • Prevalence labels use the Tranco top 1-2500 calibration set, an approximately 2,505-scan directional calibration set.