Understanding the customers directory

Availability

Customers is in private beta. The page is visible to everyone under Audience → Customers, but until your organization is enabled the directory is shown as a blurred sample so you can see what it looks like. Use Request early access on that page to register interest.

What it is

Customers is a unified directory of every person engaging with your project across AppGram — wishboard voters, roadmap watchers, survey respondents, status page subscribers, and support requesters.

Every visit is captured anonymously by default, then enriched into a fuller profile as you learn more about the person. The result is one coherent picture of who you're building for, instead of the same human appearing as five unrelated rows in five different modules.

The three identity tiers

Every record sits at one of three tiers, depending on how much you know about them:

• Anonymous — someone who used your public pages without telling you who they are. You get activity and rough location, nothing more.
• Self-identified — they typed an email into your portal. Useful, but unverified: an email someone types could belong to anyone.
• Verified — your own backend has vouched for them with a signed token, so their identity, plan, and attributes are trustworthy.

You don't have to reach Verified. It simply gives you the most to work with — see Setting up verified identity.

Browsing the directory

The table lists each person with their tier, location, and when they were last seen. Above it you can:

• Search by email — the fastest route to a specific person.
• Filter by tier — all tiers, verified, self-identified, or anonymous.

Those two are the only filters today. You cannot yet filter the directory by plan, by a custom attribute, or by something a person did — see What the directory does not do yet below.

Four summary metrics cover the last 30 days: New people, and how many of those were Verified, Self-identified, and Anonymous. Watching the verified share climb is the clearest sign your identity integration is working.

What a customer record holds

Open a person to see their full profile:

• Identity — name, email, external id from your own system, and tier.
• Location — country, region, and city.
• First seen and Last seen — the span of the relationship, and the best available signal of whether someone is still active.
• Support activity — total, open, and resolved tickets, plus the most recent one.
• License keys — any keys issued to this person, with their seat usage.
• Attributes — whatever your backend sends: plan, seats, signup date, role, MRR, feature flags, anything you choose.

What the directory does not do yet

Worth being explicit, because it changes how you design around it:

• There is no per-customer activity feed. A record does not list voted on this request or answered that survey. You get first seen, last seen, and a support summary.
• You cannot query by behaviour or attribute. The directory filters on tier and email only.
• There is no automation trigger for customer activity. Automations fire on module events — a request was filed, a ticket was opened, a payment failed — not on a change to a customer record.

The practical consequence: catch behaviour at the moment it happens, using the module event that describes it, rather than trying to poll the directory for it afterwards.

What a customer record unlocks elsewhere

• Support inbox — plan, seats, signup date, and account history sit next to the conversation, so your team replies with context from the first message.
• Automations — a workflow can branch on whatever the triggering event carries about the person, so verified attributes let you route a premium customer's ticket differently from an anonymous one.
• License keys — keys are bound to a customer record, so support can see what someone was issued.

License keys

If you sell distributed software, the directory also mints and manages license keys — bound to a customer or standalone, with a seat limit, an optional expiry, and an activation list per device. Use Mint license key in the page header, or the license section on a customer's record.

See License keys for the full guide, including the one-shot key reveal and the difference between revoking and deleting.

Getting the most out of it

• Send attributes you'll actually act on. Plan, seats, and signup date earn their keep; a field nobody uses is noise.
• Don't dismiss anonymous records. They're the top of your funnel, and they become self-identified or verified as the relationship develops.
• Check support activity before replying to a ticket from an unfamiliar name — the history is usually the context you were about to ask for.