First-party data: the records you already own.
The form on your website, the contact in your CRM, the payment in your Stripe account: your business wrote each of those records itself. This page defines the term, says where each record sits when the Command Center reads it, and says what stays with you if you leave.
What is first-party data?
First-party data is what your business collects itself, on its own properties, from people who chose to deal with you. A visitor fills in the quote form on your website. A customer pays an invoice. A prospect moves from new to quoted in your CRM. Your systems wrote each of those records, and nobody else stood between you and the fact.
The term exists to separate your records from two other kinds. Second-party data is another company's first-party data, shared with you under an agreement. Third-party data is bought from a vendor who collected it from people who never dealt with you, and who may sell the same rows to your competitors. A lead bought from a marketplace is the local-service version: collected on the marketplace's property, not yours, and shared. Compare a purchased lead with one from your own forms.
Which of my records are first-party data?
Four records, and your business already holds most of them. The lead sheet your website writes: on every form submission the form handler appends a row server-side, with the name, contact details and what the person needs and, where the site captures them, the page they were on, the source they arrived from, the landing page, the referrer and any campaign tag on the link. Your CRM: contacts, pipeline stages and the source recorded on each. Your Stripe account: payments, subscriptions and recent charges. Your booking platform, where the business runs on one: jobs and the job pipeline. Send email through a platform and its campaign statistics are a fifth.
Google Analytics and Google Ads are measurements, not records. They watch activity on your property, but a tag in the visitor's browser takes the measurement, Google's system holds it, and it publishes hours behind. The lead sheet records what happened; the analytics measure it. That difference decides how to read key events and conversions: a measurement can be wrong about a form submission, and a row written server-side at the moment of submission is the record of it.
Why does my own record beat the platform report?
Because the platform report can stop being true without telling you, and your own record keeps counting. A browser tag gets blocked, or breaks after a site change. A conversion label gets renamed. A platform changes what it counts. A row appended server-side on submission depends on none of that: no tag has to fire and no analytics cookie has to survive. Where the site captures them, the source, landing page and referrer ride along in the submission itself, noted on the visitor's first page. That is how the source of each lead is captured without an analytics tag.
On one account we manage, a tag change silently stopped every conversion for six weeks. Twenty-one real leads landed in the lead sheet while Google Ads reported zero. The owner believed the platform, paused the campaign that carried every counted lead and cut its budget 90 percent. The first-party record was right the whole time; nobody was reading it against the report. Today a daily lead watch, on the instance whose forms feed the sheet, reads the two against each other at 7:20am Eastern and raises when they diverge. It can do that because the sheet exists.
Where does my data sit when the Command Center reads it?
In your accounts, with two exceptions named below. The Command Center reads your data where it lives instead of copying it into ours. Where your forms feed it, lead rows live in a Google Sheet your own site's form handler writes on every submission, and every lead is emailed to your team as it lands; the Leads view reads that sheet newest first. The outcome you set on a lead is kept in a separate record on our service, and nothing on the screen writes to the sheet. Your CRM, Stripe and booking platform stay where they are, read through access you grant during setup; nothing on the screen writes to any of them, and the Stripe connection never creates a charge or a refund. Content produced for you is filed as a Google Doc in a client folder on our Drive.
Five things sit with us. The dashboard snapshot, the numbers you see, served from a managed cloud service. The per-client map that says which of your accounts is which. The outcome record for each lead. The requests you send from the screen, logged. And, today, the lead sheet itself, held in our Google account and read by the Leads view. Not connected on any client instance: your email inbox, your calendar, and your customers' payment card data, which Stripe holds and we never read. Read the full statement, including who can open the dashboard, on the page about what we read and where it lives.
What do I keep if I stop?
Everything you started with, plus every lead already emailed to your team. Every tier is month to month. Stop, and you revoke our manager access in your own Google consoles and your seats are closed. Your CRM, Stripe and booking platform were always yours and stay yours. There is no export to request for those.
Where each first-party record sits.
| Record | Who holds it | What the Command Center does with it |
|---|---|---|
| Website form submissions | A lead sheet your site writes on every submission, where your forms feed one | Reads it newest first; keeps the outcome you set in a separate record; never writes to the sheet |
| CRM contacts and pipeline | Your CRM, GoHighLevel today | Reads stages and sources; nothing on the screen writes to it |
| Payments and subscriptions | Your Stripe account | Reads records; never creates a charge or refund |
| Jobs and job pipeline | Your booking platform, where you run on one | Reads it live |
| Email campaign statistics | Your email platform | Reads statistics, live |
| Inbox, calendar, card data | Not connected | Nothing |
A form submission written server-side to the lead sheet is a record, a conversion counted by an ad platform is a measurement of it, and when the two disagree the record wins.
Questions, answered.
What is the difference between first-party and third-party data?
You collect first-party data yourself, on your own properties, from people who dealt with you. Someone else collects third-party data, from people who never dealt with you, and sells it on, usually to more than one buyer.
Is Google Analytics first-party data?
Its origin is, its measurement is not. It measures your own property, but a tag in the browser takes the measurement, Google's system holds it and it publishes hours behind. Treat it as measurement about your records, not the record itself.
Is a lead I buy from a marketplace first-party data?
No. The marketplace collected it on its own property, and it is a shared lead. The Command Center counts leads from your own forms and your own CRM.
Who owns the lead sheet?
The rows are your business's records. The sheet itself is held in our Google account today, and every lead is emailed to your team as it lands. The Command Center reads the sheet; the outcome you set on a lead lives in a separate record on our service, and nothing on the screen writes to the sheet.
Do you read my customers' card data?
No. Stripe holds it. We read payment and subscription records and never create a charge or refund.
What do I keep if I leave?
Your CRM, Stripe, booking platform and Google accounts, with our access revoked by you, plus every lead already emailed to your team.
See it running
before you decide.
The demo is the real product on a fictional company, with no form in front of it. Pricing is three published tiers. Setup on your own accounts takes two to four weeks.
Open the live demo See pricing
New here? See what the Command Center is. Prefer to write? Send us the one thing you want to know.
- Refreshed when you open itLive data on page load, never a monthly PDF
- Counted from your own formsLeads recorded server-side, compared daily with Ads and GA4
- Four answer engines, measuredChatGPT, Gemini, Claude and Grok, with a published denominator
- A review-first queue on every sendEvery draft waits in a review-first queue and every send is logged.