Main Header

PostHog for SignalPress

Updated on July 30, 2026

Use Settings to configure delivery, Routing to select events, Logs to inspect delivery history, and Help for this guide. Routing requires Tier 1; Tier 2 adds request rules. Log visibility, payload previews, and deletion can be delegated separately with Tier 2 role permissions.

Send signals to PostHog for product analytics and event logging.

PostHog is a premium SignalPress service. The active license must include service_posthog or *.

Hub service ID: posthog. Index: Integrations Overview. Target from PHP: Service Targeting.

Get the project token

  1. Sign in to the [PostHog app](https://app.posthog.com/) and open the project that should receive WordPress events.
  2. Open Project settings (gear icon in the left sidebar, or Settings → Project).
  3. Under Project API key, copy the Project token. PostHog may label this as the project API key; SignalPress uses it as the Project Token.
  4. In SignalPress, activate PostHog, paste the token into Project Token, and confirm the Host matches your PostHog region:
  • United States (default): https://us.i.posthog.com
  • European Union: https://eu.i.posthog.com
  • Self-hosted: your PostHog instance URL, such as https://posthog.example.com
  1. Choose the tracking channels you need, enable the service, and save.

Shared Settings fields on every integration also apply:

  • Use custom project name (Pro) — override the global project for PostHog events only.
  • Show JavaScript activity in the browser console (Tier 1+) — logs PostHog SDK activity when the browser SDK is loaded.

Treat the project token as a secret. Do not publish it, commit it to source control, or expose it in public page markup unless you intentionally load the PostHog browser SDK.

  • [PostHog project settings](https://posthog.com/docs/settings/project-details)
  • [PostHog capture API](https://posthog.com/docs/api/capture)

Test the connection

  1. Keep the PostHog Activity or Events view open for the destination project.
  2. In SignalPress, click Send test signal.
  3. Confirm signalpress test appears in PostHog within a few seconds.

If the test fails, recheck the project token, host region, and that the PostHog project is active.

Tracking channels

  • Server-side event tracking sends PHP and JavaScript capture events through WordPress with sp_capture() / SignalPress.capture().
  • Browser analytics loads the PostHog SDK when the service is enabled with a Project Token and Host. Use SignalPress.analytics() for manual browser events.
  • Web analytics adds automatic pageviews, page leaves, and autocapture through the same browser SDK.
  • Session recording is currently disabled explicitly by SignalPress.

Send a signal (PHP or JavaScript)

PHP

sp_capture(
    'checkout_completed',
    [
        'order_id' => 123,
        'total'    => 49.95,
    ],
	[
		'source'      => 'checkout',
		'distinct_id' => 'customer-42',
		'services'    => [ 'posthog' ],
	]
);

JavaScript

SignalPress.capture(
	'checkout_completed',
	{
		order_id: 123,
		total: 49.95,
	},
	{
		source: 'checkout',
		distinct_id: 'customer-42',
		services: [ 'posthog' ],
	}
);

Caller data is nested under PostHog's payload property. Shared context such as project, environment, source, and distinct ID remains at the top level.

Logged-in server and browser events also include the numeric wp_user_id. PostHog browser analytics continues to identify the visitor with wp-user-{ID}; wp_user_id is additional correlation metadata and does not replace PostHog's distinct_id.

Browser analytics

When PostHog is enabled with a Project Token and Host, the browser SDK loads automatically. Send manual browser events with:

JavaScript

SignalPress.analytics(
	'cta_clicked',
	{
		location: 'homepage',
	},
	{
		source: 'marketing-site',
	}
);

Analytics events bypass WordPress routing and do not create delivery-ledger rows. Use JavaScript capture when you want normal server routing to PostHog or other services.

Server-side event routing

PostHog can filter server-side events before delivery using its routing settings:

  • Routing Environment limits delivery to production, staging, development, or local events.
  • Routing Minimum Level filters using debug, info, warning, error, and critical. Missing or invalid levels are informational.
  • Include Event Patterns, Exclude Event Patterns, and Include Sources use removable filter tags with exact values or * and ? wildcards. Press Enter or type a comma to add a tag. Blank include fields match everything, and exclusions always win.

Routing affects server-side delivery only. PostHog browser analytics and automatic web analytics keep their existing behavior. Filtered server-side events appear in the delivery ledger with the reason they were skipped.

The dedicated Routing tab shows No filters or the active-filter count in its tab label.

Example: use checkout_*, payment_* as included events, payment_retry_started as an exclusion, and checkout as the included source.

Filters

  • signalpress/posthog/payload adjusts the server-side PostHog request body.
  • signalpress/posthog/load_browser_tracking can prevent the browser SDK from loading, commonly until consent is granted.
  • signalpress/posthog/load_web_analytics remains available as a compatibility alias for the browser-loading filter.

Troubleshooting

  • Tracking controls stay disabled until a Project Token is saved.
  • Web Analytics can be enabled independently of manual analytics calls.
  • Analytics events go directly to PostHog and do not create WordPress delivery-ledger entries.
  • Server-side delivery is non-blocking; the connection test performs the blocking response check.

See [PostHog](https://posthog.com/) and the [PostHog app](https://app.posthog.com/).