Privacy

This page describes what the product actually does with visitor data. It is a description of behavior, not legal advice, and nothing here is a compliance guarantee. What your site needs in your jurisdiction is your call to make — ideally with someone qualified to make it.

LaunchPulse uses a cookie

Let’s be direct about this, because plenty of analytics tools are cagey about it.

LaunchPulse sets a first-party cookie, _lp_vid. It holds:

• a random visitor id
• a session id
• first-touch attribution

It’s first-party and it’s not used for advertising, but it is a cookie. Cookie-consent obligations may apply to your site depending on where you and your visitors are. You are responsible for your own compliance — your banner, your policy, your legal basis. LaunchPulse doesn’t decide that for you and can’t.

IP addresses are never stored

The visitor’s IP address is used only to derive a country, and then it’s discarded. It is never written to storage.

What’s kept is the country column: an ISO-3166 alpha-2 code. US, MX, DE. Nothing narrower — no city, no region, no network.

What LaunchPulse does not do

• No cross-site tracking. The cookie is first-party. There is no identifier shared across other people’s sites.
• No advertising identifiers.
• No data selling.
• No third-party sharing.

The collector receives only what your site sends it. There is no enrichment step, no identity graph, and no external data source being joined onto your visitors.

What’s collected automatically

Per event:

• page path and full URL
• referrer
• UTM parameters, and the source / medium / campaign derived from them
• country (from the discarded IP)
• device, browser, operating system
• timestamps
• visitor id, session id, and user id if you’ve set one

The complete column list is in Data model.

You decide what else is sent

This is the part under your control, and the part where mistakes are made.

identify() takes YOUR internal user id. A database id, a UUID — whatever your system uses to mean “this account.” The SDK warns in the browser console if the value you pass looks like an email address, because that’s the most common mistake.

Never put emails, names, phone numbers, or other personal data in identify() or in event properties. properties stores whatever you hand it. It doesn’t inspect or filter your data, so if you send a full name, a full name is what gets stored.

Send an id. Look up the person in your own database when you need to know who they are. See Identifying users.

Resetting a visitor

lp.reset() clears the client-side state:

• rotates the visitor id
• rotates the session id
• clears the user id

Call it on logout, and on any request from a visitor to be forgotten client-side. After a reset, the browser is a new anonymous visitor with no link to the previous id.

Note what this is: a client-side reset. It stops future events from being tied to the old identity. It doesn’t reach back and change events already stored. See SDK reference.

Data retention

Deleting a project is a soft delete. The project disappears from the app, but the analytics data is retained.

Alert firing history is purged after 90 days.

If you need something beyond that, ask — but plan around what’s written here, not around an assumption.

Practical guidance

Four things that keep you out of trouble:

1. Treat _lp_vid as a cookie in your privacy policy and your consent flow. Because it is one.
2. Never send personal data. Send ids. The join belongs in your own database.
3. Say what you collect. The list above is short and honest enough to paraphrase directly into a privacy policy.
4. Wire up lp.reset() at logout. It’s one line and it does the right thing on shared computers.

What’s next

• Data model — every column stored on an event.
• Identifying users — using identify() correctly.
• Security — protecting your own account.