Implementation

Architecture

One product, three independent layers

core

Bridgee Attribution

Link and Blink preserve the origin; the SDK solves the installation; the channel reaches Firebase/GA4.

Quality

Traffic Intelligence

CTIT, replay, journey depth and trust score with components and reason codes.

Physicist

Physical Intelligence

Cameras and sensors generate aggregated counts, occupancy, dwell, and cohorts.

Animated flow

From click to channel on the GA4

Follow attribution from the click to delivery in GA4.

1. ClickBlink preserves allowed IDs and UTMs.

2. InstallationSDK performs the match.

3. DecisionMethod, confidence and reason codes.

4. Firebase/GA4Channel delivered without duplication.

Start here

Implementation checklist

Create tenant and test environment

Define domains, destinations, windows, consent and technical contacts.

Configure CNAME and Blink

Use HTTPS, parameter allowlist, and one test URL per platform.

Install the SDK

Android, iOS or React Native; perform first-open only according to the documented cycle.

Validate the decision

Check match method, confidence, decision version, reason codes and idempotence.

Validate Firebase/GA4

Ensure single attribution delivery and preserve the Google's native attribution.

Technical onboarding

Credentials and required information

Each customer receives a Tenant ID and a Tenant Key to authenticate reconciliation requests. During onboarding, provide the company, app store links, technical owners and Blink domains.

Individual issue

Credentials are separated by tenant and environment. Production and testing share no secret.

Safe delivery

Keys are sent via an authenticated channel, never in a public ticket, analytics or example code.

Rotation

Plan ownership, expiration, revocation, and rotation without disrupting the application.

Contact listed in the legacy documentation: bridgee@caaqui.com. Before production, confirm the SLA and operational contact during onboarding.

Blink Server

Domains, CNAME, TLS and validation

The documented design uses customer-controlled subdomains for iOS and Android. Choose short, recognizable names such as ios.suaempresa.com.br e android.suaempresa.com.br.

Type	Example host	Documented destination	TTL	Platform
CNAME	`ios.suaempresa.com.br`	`blink.bridgee.ai`	300	iOS
CNAME	`android.suaempresa.com.br`	`blink.bridgee.ai`	300	Android

confirm the final endpoint received in onboarding before changing DNS;
validate propagation with dig ou nslookup;
the legacy flow provides TLS provisioning by Bridgee after confirmation from hosts;
test HTTPS, redirect, allowlisted parameters and destination for each platform;
Do not publish campaign links before routing and certificate validation.

SDKs and examples

Official implementations of the Bridgee

The SDKs and sample apps below are maintained in the official organization bridgee-ai. Links open GitHub in a new tab.

Platform	Official SDK	Sample application
Android/Kotlin	bridgee-android-sdk ↗	bridgee-android-example ↗
iOS / Swift	bridgee-ios-sdk ↗	bridgee-ios-example ↗
React Native	bridgee-react-native-sdk ↗	bridgee-react-native-example ↗

For production, confirm the approved release, compatibility, artifact checksum and environment credentials in onboarding. Talk to contato@bridgee.ai.

The lifecycle of firstOpen and the public API must follow the approved project release; validate the sample app before promoting the integration.

First access

From SDK to Firebase/GA4

In the first eligible cycle, the SDK initializes the approved technical identifier, calls the reconciliation service, and receives the acquisition metadata. Then, the resolved source is made available to the Firebase/GA4 as per the release contract.

initialize the SDK once in the documented cycle;
use correct tenant credentials and environment;
treat success, no match, timeout and repetition with idempotence;
validar source, medium, campaign, method and confidence;
preserve native attribution and prevent duplicate delivery;
confirm in DebugView/test and then in the acquisition report.

Neutral contract

Accepted identifiers

Partner	Evidence	Rule
Google	`gclid`, `gbraid`, `market_referrer_gclid`	Preserve native flow and prevent duplication.
Meta	`fbclid` or approved payload	Keep opaque; postback requires approved contract.
TikTok	`ttclid` or approved payload	Routing configured per tenant.
DSP	macro in `partner_click_id`	There is no universal macro.
Bridgee	`bridgee_click_id`, `bridgee_install_id`	Pseudonymous correlation; never a person's identity.

SDK

Versioned match response

{
  "utm_source": "tiktok",
  "utm_medium": "paid_social",
  "utm_campaign": "launch",
  "attribution": {
    "resolved_partner": "tiktok",
    "evidence_type": "ttclid",
    "match_method": "deterministic",
    "match_confidence": 1.0,
    "partner_conflict": false,
    "decision_version": "partner-routing/1.0.0"
  }
}

IDs are case-sensitive and opaque. Never choose a channel based on commercial priority; Conflicts are audited and suppress postback.

Quality

Web, app and absence of GTM

Web + GTM

Checkpoint enabled with active time, depth, sequence and idempotent key. The browser does not calculate scores.

App+BigQuery

Authorized view of Firebase native events. Does not collect purchases.

App without access

Push server-to-server, SDK checkpoints or behavioral status unavailable.

Contrato session-quality/1.0.0: allowlisted raw evidence → server validation and deduplication → explainable features → versioned antifraud and Trust Score. Revoking analytics_storage stops collection and clears local state.

Privacy and operation

Gates before production

consent and purpose by region;
no raw IP, PII or secrets in analytics;
retention and deletion per tenant;
contract tests Android, iOS, React Native and API;
shadow scoring before affecting decisions;
rollback by feature flag.