PostHog Setup: Account, Organization, Project, and Tracking

Before signing up, decide:

• Who should own the PostHog organization.
• Whether you need the US or EU Cloud region.
• Which website, app, or product you want to track first.
• Whether this is for your own company, a client, or an agency-managed workspace.
• Which platform you will install PostHog on, such as WordPress, Shopify, ClickFunnels, a SaaS app, or a custom website.
• Which conversion events matter most and how you will identify users.
• Who needs admin access and who only needs member access.

For most teams, start with PostHog Cloud.

PostHog Cloud is quicker to set up and requires no infrastructure work, so you can start testing your tracking without maintaining a server.

Self-host only if you need control that Cloud cannot provide and have a team prepared to maintain the infrastructure long term. Self-hosted PostHog has no commercial support or recovery guarantee. (+)

Sign up

Create an account on US Cloud or EU Cloud. Choose the region and owner using Steps 2 and 3 before submitting the form.

Developers can also sign up with the PostHog wizard, which creates the account and installs the SDK in one command; it is covered at the install step in Step 6.

If an agency is helping with setup, use the web signup so the client can own the organization. Use it for WordPress, Shopify and ClickFunnels too, where there is no app codebase to run the wizard in. Then follow the platform guide in Step 6.

PostHog Cloud is available in US and EU regions. EU Cloud runs on servers in Frankfurt. (+)

Use:

• US Cloud if your company and audience are mainly US-based and you do not have EU data residency requirements.
• EU Cloud if you operate mainly in Europe, serve EU users heavily, or have stricter EU data residency expectations.

Your region is fixed when the account is created. Once events, dashboards, integrations, and billing are active, moving regions becomes a migration project.

Cross-region project migrations are available with Scale or Enterprise and must be run by a PostHog engineer. (+) Confirm eligibility with PostHog support before planning a move. Moving a project between organizations in the same region is self-serve. (+)

If you are an agency, choose the region based on the client’s requirements, not your own convenience.

Use an email address the company controls for its owner account. A freelancer’s personal address or an employee’s temporary inbox can make it difficult to keep access when they leave.

The owner of the PostHog organization should be the company or client that owns the data. Contractors and agencies can be invited as collaborators.

Better options:

• Use a company-owned email.
• Use SSO if available.
• Keep the Owner role with someone at the company. Only an Owner can transfer or delete the organization, and an organization can have more than one Owner, so add a second company Owner early. (+)
• Give a technical lead and a business lead admin access.

The company should still have an Owner after a contractor or employee leaves.

In PostHog, the organization is the top-level workspace for projects and members.

Think of your organization as the company and your project as the individual product or site you’re analyzing.

Use one organization per business or client.

For agencies, we recommend:

One client = one PostHog organization owned by that client

Join the client’s organization as a collaborator so they keep ownership when your work ends.

If a client will not own an organization, use a separate project for each client in the agency’s organization. Plan how you will hand it over later, and check the billing and access limits: every project beyond the first needs the paid plan, and all projects share one bill and one free allowance. (+) On the free and pay-as-you-go plans, every member can open every project. (+) A client you invite can therefore see your other clients’ data. Restricting access by project needs a Boost, Scale or Enterprise package.

A later project transfer requires an owner or admin in both organizations and at least two projects in the source organization. (+) Agree on that handoff before choosing the fallback.

A PostHog project is where your product’s data and settings live. A new organization already has a Default Project; rename it for the product or site you are measuring.

Use one production project for each connected customer journey.

Keep connected landing pages in the same project so you can follow the journey between them.

PostHog strongly recommends keeping your marketing website and apps in the same production project. (+) That makes it easier to follow users across the full path from visit to signup to product usage. With the default cookie-based configuration, a visitor’s identity carries across subdomains of one domain; separate domains need the IDs passed across. (+)

Split projects only when the data should stay separate.

Good reasons to create separate projects:

• Different brands with separate audiences.
• Production and internal tools that should not mix.
• Different products with different users and reporting needs.

Bad reasons:

• One project for each page.
• One project for each short campaign.
• One project for each team member’s experiment.

For environments, PostHog recommends separate Local Development, Staging and Production projects so test data stays separate. The free plan includes one project; adding a card unlocks the paid plan with a $0 monthly base price and six projects. (+) Those projects still share the organization’s free allowance.

If you stay with one project, keep local and staging traffic out of capture. In the JavaScript SDK, opt_out_capturing() stops capture; check the environment before initialization so test traffic is not sent first. (+) Use an internal-user filter for traffic you need to capture but exclude from reports. Follow When to stop capturing instead to choose between these controls.

Before installing, choose the events you need and the data you should keep private. Then install the snippet or SDK and connect the sources those reports need.

Decide What to Track First

You do not need to capture every interaction to get started.

Start with the completed actions you need to measure. For example:

For SaaS:

signup_completed
subscription_started
plan_upgraded
feature_used

For ecommerce:

product_viewed
add_to_cart
checkout_started
order_completed

In lead generation:

lead_submitted
call_booked
quiz_completed
deal_won

Then add properties you will actually use for segmentation:

plan_type
traffic_source
utm_campaign
country
device_type
customer_type

Use the event tracking plan to define each event’s trigger, properties and user ID before implementing it.

Decide how you will identify users, too. Call identify() when you have a stable user ID and need to connect that person’s activity, such as at login or signup. (+) Anonymous events can still power trends and funnels; identification is needed when you want person properties or to connect a known user’s journey across visits and devices. (+) Call reset() when a user logs out, so the next person on a shared device is not merged into their profile. (+)

The JavaScript SDK defaults to person_profiles: 'identified_only', so anonymous visitors do not create person profiles. (+) Calls such as identify(), alias(), group() or setPersonProperties() create a profile; subsequent events for that user are identified events. (+)

Check the snippet you actually install: person_profiles: 'always' creates profiles for every visitor. Identified events cost more than anonymous events above the free allowance; use Reduce identified-event costs to decide when that extra data is worth collecting.

Choose autocapture for the interactions you need to explore, heatmaps for the pages where you need click and scroll patterns, web vitals when you will investigate page performance, and session recording only after deciding what can be recorded safely. On the free plan, PostHog collects heatmap data for up to three pages you choose. (+)

Choose Consent, IP Capture and Session Replay Settings

If tracking on your site depends on consent, load PostHog opted out and let your consent banner opt visitors in: set opt_out_capturing_by_default: true and opt_out_persistence_by_default: true, so nothing is captured and no analytics identifiers are stored before the visitor agrees, then call posthog.opt_in_capturing() or posthog.opt_out_capturing() when the visitor chooses. (+)

EU organizations default to IP capture disabled, and each project can override the organization setting. (+) Changing the organization default affects new projects, so check existing projects separately.

PostHog can still use an IP for GeoIP enrichment before discarding it. (+) Without an IP at enrichment time there is no IP-based geolocation. If you do not send an IP to Meta, you also lose one customer matching signal. (+) Use our IP capture guide to decide whether you need to retain that data.

Decide whether to record sessions before traffic arrives. Use our session replay guide to choose what to record and how to protect sensitive fields.

Install the Tracking Snippet or SDK

Set the privacy choices above, and the billing limits in Step 8 if you added a card for extra projects in Step 5, before capture starts on your running site or app.

Use the JavaScript snippet for a website, or the relevant SDK for your app. Find the project token and host in your project settings.

If you have a supported app codebase and no account yet, you can create your account and install PostHog with the wizard:

npx @posthog/wizard@latest --signup --email [email protected] --region eu

Replace [email protected] with the owner’s email and use --region us for US Cloud. The wizard creates the account, provisions a project in that region, installs the SDK, and writes the project token and host into your codebase.

To use the web app afterwards, set a password through the welcome email. (+) Wizard signup does not create a personal API key. (+)

For an existing account in a supported codebase, run the wizard without --signup:

npx @posthog/wizard@latest

For platform-specific placement and testing, follow our WordPress install guide, Shopify install guide or ClickFunnels install guide.

Confirm the API Host Matches Your Region

Your snippet’s api_host must match your project’s Cloud region:

US: https://us.i.posthog.com
EU: https://eu.i.posthog.com

Connect Only the Data Sources You Need

You can sync external databases, CRMs, payment processors and ad platforms into PostHog to query them alongside your events. (+) Connecting a source starts syncing rows; choose the tables and schedule you need.

Synced rows have a 1,000,000-row monthly free allowance; each new source also gets seven days of free historical syncs. Use Reduce data warehouse and destination costs before enabling large or frequent syncs.

In the interface shown below, open Settings → Project → Product analytics for time zone, week start, and internal and test users.

Set the Timezone

Match the time zone your ad platforms, such as Meta Ads or Google Ads, and revenue reports use so the daily reporting boundaries line up.

If those systems use different time zones, choose the one you reconcile against, usually revenue reporting or the ad account. Otherwise, the same purchase can fall on different days in the two reports.

Set the Week Start

Choose the week start that matches your business reporting.

The screenshot uses Sunday; choose Monday if that is when your weekly reports begin.

Exclude Internal Traffic

Filter out your own team as early as possible. While your team keeps testing the product, your top users, top sessions and conversion paths may just reflect your own setup activity.

Options include:

• Excluding company email domains.
• Filtering office IP ranges where IP data is available.
• Marking staff users with a property such as internal_user = true.
• Excluding staging and test hosts from reports.

Enable the filter for new insights and apply it to existing insights too. (+) Defining a rule alone does not switch filtering on, and filtering reports does not stop events being ingested.

The free plan needs no credit card and includes one project, one year of event retention, unlimited team members, and monthly free usage allowances. (+) Usage stops at those allowances.

Open the organization’s billing settings, rather than the project settings. Set every available product billing limit to $0 until you know your volume, then raise each one deliberately. (+)

A $0 limit keeps usage within the free allowance. At a product’s limit, PostHog stops ingesting and processing its data; additional data is lost permanently. If the feature flag limit is reached, SDKs return default flag values. (+)

Billing alerts are sent at 80% and 100% of both the limit and the free allowance, and owners and admins receive the emails. (+ / +)

If you use Logs, custom retention is billed separately and cannot have a billing limit. (+)

Usage can grow quickly if autocapture is noisy, bots hit your site, internal testing or multiple environments send events, session replay records high traffic, or feature flag requests fire on every page. Use our cost guide to reduce that volume before raising limits.

Give admin access to the people responsible for tracking settings and billing. Invite everyone else as members.

This limits who can change settings and billing. It does not restrict members to viewing reports:

On the free and pay-as-you-go plans, members can still edit every project’s insights, dashboards, feature flags and experiments; admins can also manage billing, members and project settings. (+)

Once the snippet is installed, check what PostHog receives.

Make a test visit to your site or app and complete the action you want to measure.

Then open the Activity tab in PostHog and check the events from that journey:

• A $pageview appears for each page you opened, including pages reached through in-app navigation, without duplicates.
• The event URL is correct.
• The region and API host are correct.
• Browser events within one session share a $session_id, and logging out with reset() starts a new session. (+) Server-side events carry it only if your code sends it. (+)
• Each important action appears as its planned custom event, with the properties you need.
• After a test login, the events belong to the right person. Log out, log in as a second test user, and check that their events do not join the first user’s profile.
• The visitor is not incorrectly marked as a real lead or customer.
• Internal test traffic is excluded or clearly labeled.
• Billing usage looks reasonable.

Check the snippet’s defaults date, such as defaults: '2026-05-30'. Unless you set capture_pageview yourself, defaults dated '2025-05-24' or later capture a pageview on each path change in a single-page app; older or unset defaults capture page loads only. (+)

If nothing arrives, check the project token and api_host first, then consent settings that opt visitors out by default, ad blockers, and a Content Security Policy that does not allow *.posthog.com. (+ / +)

Test session replay, feature flags and experiments separately if you use them. A pageview only confirms that part of the setup. The PostHog audit covers the wider checks.

Set one PostHog alert on a saved $pageview insight to catch traffic dropping below an expected level. Choose a threshold and period that allow for your normal quiet hours, so a broken install gets noticed. Free organizations can create up to five insight alerts. (+)