EdgeKit Profile
Five systems, five versions of every reader. Profile keeps one.
One record per reader across every title — what they hold, what they told you at sign-up, how they joined — in a database you own. Every event lands in your warehouse, and signed-in readers’ events reach your marketing stack.
Access · computed by EdgeKit
- Access
- Paid
- Products
- Markets Pro
- Titles they can read
- 2 of 3
- Access ends in
- 41 days
- Lapsed
- Never
On this title
- Joined
- 19 Sep 2025
- Joined through
- Newsletter
- Newsletters
- Morning Brief · Markets Close
Answered at sign-up
- Industry
- Financial services
- Job level
- Director
- Interests
- Markets · Policy
Your fields
- account_type
- Individual
- seniority
- Senior
The reader record
Who paid, who lapsed and who never did, on one record
Login, paywall, email platform, analytics and billing each keep a copy of the reader. Profile is the one record behind your sign-in, your paywall and your billing — and the ID your email platform keys on.
Win-back
A lapsed subscriber is not a never-paid registrant
Fold both into “registered” and the win-back list goes to the wrong people. Profile keeps today’s access apart from history: what a reader can open now, and the day their last access ended — and a field of your own can name what they held.
- Access state, products held and the titles a reader can open, computed by EdgeKit on every title
- Days until access ends, and the date it lapsed
- A subscription ended by hand counts as lapsed, not only one that ran out
- Access today
- Registered
- Last held · your field
- All Access
- Lapsed on
- 14 Aug 2026
- Joined through
- Newsletter
- Access today
- Registered
- Last held · your field
- Nothing yet
- Lapsed on
- Never
- Joined through
- Sign-up
Same access today. Different history.
Your fields
Tell corporate, student and trial readers apart, without a ticket
Account type, company, seniority — whatever your business calls it. A field is a name and a short list of rules over what EdgeKit already holds: memberships, billing accounts, sign-up answers. No engineering ticket, no vendor schema.
- Any segment of readers you can describe becomes a value your paywall can target
- Publish once and every reader’s record rebuilds
Rules · first match wins
- 01Holds a company seat
membership.is_seatCorporate - 02Is in a trial
membership.is_in_trialTrial - 03Bought a student offer
membership.offer_familyStudent - Everyone elseIndividual
Sign-up questions
Industry and job level, for the teams that sell to readers
The answers your ad sales and B2B teams ask for, collected at sign-up. Declare a question in the console — industry, job level, interests — and it is collectable straight away.
- Text, numbers, yes or no, and lists — one answer or several, required or optional
- Retire a value without touching anyone’s answer: holders read the default you set
job_industry · Values
Forwarding
Start a marketing journey from what a reader did on any title
Each signed-in reader’s events reach your marketing stack as custom events on the same reader ID, so a campaign can start from what they did on any title. Every event also goes to any OTLP endpoint, and your warehouse is loaded from EdgeKit’s own archive, so it can always be rebuilt.
- Snowflake, BigQuery or MotherDuck: one table you own, for every title
- Any other tool with an HTTP API, connected on request
- BrazeCustom events · signed-in readers · on the reader IDOn
- OTLP endpointEvery event, the whole rowOn
- Warehouse · Snowflakeedgekit.events · backfilled from the archiveOn
The details
Everything else on the record
How the record stays correct, and who gets to change it.
Rebuilt when the facts change
A purchase, a renewal, a sign-up answer, a billing change, a published field: the record rebuilds itself instead of waiting for a nightly job.
Segments named once
“Subscribers ending this week” or “registered, questions unanswered” is defined once and reused by every rule that names it.
Company seats told apart
A field can read whether access comes through a company seat and which company holds it, so corporate readers are told apart from individual buyers.
Checked before it publishes
A field that reads something EdgeKit does not hold, or writes a value outside its type, is refused before any record is rebuilt.
Access stays EdgeKit’s
What a reader holds and until when is computed by EdgeKit, so nobody can redefine who has paid from a settings form.
Every field says how far to trust it
A field is only as trusted as what it reads: one built on a reader’s own answer shows as unverified, one built on access does not.
Erasure on the record
Erase a reader and every profile is deleted and refused a rebuild. Their answers are cleared, and they are unsubscribed from every newsletter list they were on.
Look any reader up
Search by name or email and see one person in one place: sign-in methods, organizations, products, newsletters, and a profile for each title.
Adoption
From first sign-in to your warehouse
White-glove onboarding: we set it up with you, start to finish.
- 01
Connect sign-in
Use EdgeKit ID, or keep your login and let ID verify against it. Each reader becomes one record across your titles.
- 02
Declare your questions
Add sign-up questions in the console. They are collectable straight away.
- 03
Define your fields
Write the fields your team needs. They are checked, published, and every record rebuilds.
- 04
Switch on destinations
EdgeKit connects your marketing stack and your OTLP endpoint, and loads your warehouse — backfilled from the archive when it is switched on.
Beside, not instead
Your email platform keeps sending. Your warehouse keeps querying.
The tools you already pay for finally agree on who each reader is. Nothing moves: not a campaign, a dashboard or a billing account.
Your email platform
Your email platform keeps your journeys, your templates and your sending. Nothing is rebuilt there.
Your warehouse
Your warehouse keeps your models. Events land in one table you own, kept and deleted on your terms.
Your login
Keep your identity provider. EdgeKit ID verifies against it, and the record still unifies.
Your billing
Your billing platform keeps billing. Its accounts sync onto the reader, so the record knows who pays.
Questions
Questions about Profile
Does Profile replace our CDP?
Yes. It is the record a CDP would hold: one record per reader with a profile for each title, segments named once, and their events forwarded to the tools you use. Every event carries its device ID, and the reader ID once they sign in, so you can stitch devices and IDs into one reader without rewriting history.
Who decides what goes on the record?
Your team, in the console: sign-up questions under Traits, fields under Profile. Every field is checked before it publishes, and the access fields stay EdgeKit’s.
Where does the data live?
In a database of your own, never a shared table. EdgeKit deploys either into your own cloud account, operated by EdgeKit under your controls, or on EdgeKit’s infrastructure with your database in a region you name. Either way the record is never pooled with anyone else’s and never resold.
Which tools can it feed?
Your marketing stack — like Braze — receives signed-in readers’ events. Any OTLP endpoint receives every event. Your warehouse is loaded from the archive: loads merge on the event ID, so a rerun or a backfill is safe, and each event’s own fields arrive as native JSON. Anything else with an HTTP API is available on request, and EdgeKit builds that connection on its side.
What happens when a reader asks to be erased?
Their details are anonymised in place and the answers they gave are cleared. Every profile they had is deleted, and EdgeKit refuses to rebuild it. They are unsubscribed from every newsletter list they were on, at your email platform.
Do we have to take the rest of EdgeKit?
No. Profile needs to know who a reader is, which EdgeKit ID provides — with EdgeKit’s own sign-in or with the login you already run. The paywall, subscriptions and newsletters are separate decisions you can take later, or not at all.