Customers

The Customers screen, at https://app.adto.app/dashboard/customers, lists every customer your app has identified by calling identify in the SDK, together with the link that brought each one in. Its header reads “Users your app identified with the SDK’s identify — and the link that brought them in.” The screen is read-only: there is no edit and no delete.

A customer exists as soon as the SDK sends an identify event with a customer ID. How to send one, and what the server stores, is in Events.

The list

Element	Behavior
Search (placeholder “Search name, email, phone or ID”)	Waits 250 ms after you stop typing, then searches on the server for the text anywhere inside the customer ID, name, email or phone. The query is cut to 200 characters. Every new search returns to page 1.
Rows	Clicking anywhere on a row opens the customer’s detail page. The name is also a link, for keyboard users.
Pagination	50 customers per page, newest first. A footer reading 1–50 of 312 with Previous and Next appears only when there are more than 50 results.

Columns

Column	What it shows
First seen	The date and time of the customer’s first identify.
Customer	The name, or the customer ID when there is no name. Under it: the email masked as e****@domain.com (the detail page shows it in full), or the ID in monospace when there is a name but no email. An amber Shared device · {n} chip appears when other customers sent events from one of this customer’s devices; its tooltip reads “Shares a device with {n} other customer(s)”.
Attributed link	/{slug} of the link credited with the customer’s install, or Organic (also when a blocked fraud rule withheld the credit).
Country	A flag and the name of the country the customer’s install request came from, by the geolocation of its network address, for attributed and organic customers alike. Unknown when no install is linked yet or its request had no country.

Empty states: “No customers yet — call AdTo.identify(customerId: …) in your app after sign-in.” and “No customers match your search.”

How a customer is tied to an install

The server resolves one install per customer, trying in order:

1. the install ID the first identify call carried;
2. the install ID stamped on the customer’s earliest event that has one;
3. the newest install on any device that sent the customer’s events, preferring attributed installs.

The third step matters because the SDK forgets the install ID across restarts; the device ID still links the events to the install.

The detail page

Opening a row loads ?id={customer_id}. The page starts with an ← All customers link, then the name (or ID), the ID in monospace, and the shared-device chip when applicable. “Loading customer…” shows while it loads; an unknown ID shows the server’s error Customer not found.

Stats

Four tiles: Events, Leads (events of type lead), Conversions (events of type conversion) and Net revenue: purchases minus refunds in your revenue currency. The profile also shows the date of the customer’s First purchase.

Profile

Subtitle: “Set by identify(). A later call replaces each field it sends; fields it leaves out keep their value.”

Field	Value
Name, Email, Phone	As sent by identify. A later identify that sends a field overwrites the stored value; a field the later call omits keeps its old value. The subtitle’s “first-seen values win” describes only the install association: the first install a customer was identified on stays attached. The email is shown in full here.
Customer ID	Your identifier.
First seen	When the customer record was created.
Last identified	The last time an identify touched the record.
First event, Last event	From the customer’s events.
Referred by	The customer whose referral this customer’s signup recorded, and the link, such as 1042 via /invite. The id opens that customer’s page; it is plain text when the app has never identified that id (a dec_referrer can name anyone); a rejected chip when a referral rule the app blocks hit, and the referral’s fraud flags. When the install’s link or tap named a referrer but the signup recorded no referral, the referrer shows muted with a not credited chip and the reason under it: the device had the app before (a reinstall), the user already had the app and updated it to a build with AdTo (an app update), the customer existed before the install, they signed up more than 30 days after it, a blocked fraud rule withheld the install’s credit, the link named the customer themself, or another customer signed up on the install first (an install credits one referral). See Referral programs.
Referred	The customers this customer referred, up to 50, newest first, each with its rejected chip and fraud flags. Each id opens that customer’s page.
Devices	Up to 20 distinct device IDs seen on the customer’s events, plus the install’s device.

Empty fields are hidden. Name, email and phone are stored in plain text; see Privacy and data.

Attribution

Subtitle: “The link click that led to this customer’s install. Open install shows why it matched or stayed organic.” Empty state: “No install linked to this customer yet.”

Field	Value
Attributed link	/{slug} as a link to the live URL for a permanent link; the slug in plain monospace when the link was temporary; the slug with a credit withheld chip when a blocked fraud rule withheld the credit; Organic otherwise.
Match	Install referrer (deterministic), Copied link (deterministic), Device fingerprint (probabilistic) or Organic; · credit withheld follows the match when a blocked fraud rule withheld the credit.
Referrer source	Which store or SDK handed over the referrer: google_play, huawei, samsung, xiaomi, vivo or meta.
Clicked at, Installed at	The server-side times of the matched click and of the install report.
Country, Region, Network	From the click, so where the link was tapped: the country and city, the region, and the network provider with its AS number. The install’s own country is under App & device; the two can differ.
Click device	The click’s device type, OS and browser, such as android · Android 14 · Chrome.
Referrer	The origin of the page that sent the click.
UTM	The click’s utm_* parameters, as source=… · medium=… · campaign=….
Link params	The tracking values stored on the click, as label=… · campaign=… · adgroup=… · creative=… · tracker=…, from the link’s Tracking fields or dec_* overrides.
Deep link	The dec_deeplink route the click carried.
Click IP	The raw IP address of the click; — when the deployment sets STORE_RAW_IP=0.
Fraud flags	A chip per fraud rule the install tripped, such as Emulator or Reused tap: amber when the rule only flags, red when a rule the app blocks acted on it. Hovering a chip explains the rule.

Below the fields, Open install opens the install detail with its attribution parts only: the verdict, its Why (the signal that named the click with the tap it named, signal by signal, or the fingerprint’s candidates with each signal marked agree, mismatch or missing), the tap and the device’s data. That is where an organic customer’s near misses show. It leaves out the app opens, events and screens, which this page already lists for the customer.

What each match method and confidence means is explained in How attribution works.

Shared device

Shown only when other customers share a device. Subtitle: “Other customers identified on one of this customer’s devices — account sharing, multiple accounts, or a test device.” A table of Customer (a link to that customer, with the email), Device ID and Last seen on device, up to 50 rows.

App & device

Subtitle: “Reported by the SDK at install; the country and IP are the install request’s.” Shown when the customer has an install; empty values are hidden.

Platform, App version (with the build number in parentheses), Package, OS (name and version), Device (manufacturer and model), Device kind, Physical device (Yes or No), Reinstall (Yes or No), App update (Yes, an existing user when the user already had the app and updated it to a build with AdTo; hidden otherwise), Screen (such as 1080×2400 @2.625x), CPU, Language, Timezone, Country (where the install request came from, with its flag), Connectivity, Carrier (MCC/MNC), Installer (the package that installed the app), Install time (device), Install IP (the raw IP of the install report; — when the deployment sets STORE_RAW_IP=0), Device ID and Install ID.

Which of these the SDK sends depends on its data tier; see Device data and privacy.

Events

Titled Events ({total}), where the total counts every event of the customer. The table shows the latest 200, newest first.

Column	Value
When	Date and time.
Type	A chip: conversion (green), lead (orange), identify (blue) or custom (gray).
Name	The event name, or —.
Revenue	The amount followed by its currency code, such as 9.99 EUR, or —.
Link	/{slug} when the event is attributed, or —.
Metadata	The event’s JSON, shortened; hover to see it formatted in full.

Empty state: “No events for this customer.”

Screens

Subtitle: “App sessions on this customer’s devices, newest first, with the screens shown in each: the whole session, so the screens before sign-in too. Screen views count in no total.” A session is one run of the app, by the SDK’s session id; it belongs to the customer when they signed in (identify) during it or it ran signed in, so the screens before identify show with the rest. Each session shows its date and time (the device’s clock at its first screen), the link that opened the app when there was one (opened by /{slug}), how many screens it had, and the screens in order, each with its time on hover. The 20 newest sessions are listed, with the first 50 screens of each and “and {n} more” beyond. The screens come from the SDK’s trackScreenView or its navigator observer; without them the section says so. The install detail on Overview has the same list for one install.

App opens

Shown only when there are any. Subtitle: “Times an AdTo link re-opened the installed app on this customer’s devices.” Each row is /{slug} with the date and time; the latest 50 across the customer’s devices.

Personal data

At the bottom of the page: Download everything stored (JSON) saves what AdTo holds about the customer (the record, its events, its referrals and its devices), and Erase this customer deletes it after a confirmation, together with each device only this customer used. A device another customer also used keeps that customer’s data. The page then shows what went, for example “Customer erased: 1 customer record, 1 device, 1 install, 5 events”. Both are recorded in the audit log without the customer id. What each covers is in A request from one person.