vybekiit 0.7.34 → 0.7.35

package/dist/global-skills/instrument-product-analytics/references/go.md

@@ -2,18 +2,32 @@
 
 # Go
 
+Canonical URL: https://posthog.com/docs/libraries/go
+
+> **Cloud region:** This page uses US Cloud hosts. For an EU Cloud project, use `https://eu.i.posthog.com` instead of `https://us.i.posthog.com` (ingestion host).
+
+## On this page
+
+- [Installation](#installation)
+- [Identifying users](#identifying-users)
+- [Capturing events](#capturing-events)
+- [Person profiles and properties](#person-profiles-and-properties)
+- [Alias](#alias)
+- [Request context](#request-context)
+- [Feature flags](#feature-flags)
+- [Experiments (A/B tests)](#experiments-ab-tests)
+- [Error tracking](#error-tracking)
+- [Group analytics](#group-analytics)
+- [Thank you](#thank-you)
+
 This library uses an internal queue to make calls fast and non-blocking. It also batches requests and flushes asynchronously, making it perfect to use in any part of your web app or other server-side application that needs performance.
 
 ## Installation
 
-Terminal
-
 ```bash
 go get github.com/posthog/posthog-go
 ```
 
-Go
-
 ```go
 package main
 
@@ -37,16 +51,14 @@ func main() {
 
 ## Identifying users
 
-> **Identifying users is required.** Backend events need a `distinct_id` that matches the ID your frontend uses when calling `posthog.identify()`. Without this, backend events are orphaned — they can't be linked to frontend event captures, [session replays](/docs/session-replay.md), [LLM traces](/docs/ai-engineering.md), or [error tracking](/docs/error-tracking.md).
+> **Identifying users is required.** Backend events need a `distinct_id` that matches the ID your frontend uses when calling `posthog.identify()`. Without this, backend events are orphaned — they can't be linked to frontend event captures, [session replays](https://posthog.com/docs/session-replay.md), [LLM traces](https://posthog.com/docs/ai-engineering.md), or [error tracking](https://posthog.com/docs/error-tracking.md).
 >
-> See our guide on [identifying users](/docs/getting-started/identify-users.md) for how to set this up.
+> See our guide on [identifying users](https://posthog.com/docs/getting-started/identify-users.md) for how to set this up.
 
 ## Capturing events
 
 You can send custom events using `capture`:
 
-Go
-
 ```go
 client.Enqueue(posthog.Capture{
   DistinctId: "distinct_id_of_the_user",
@@ -56,13 +68,11 @@ client.Enqueue(posthog.Capture{
 
 > **Tip:** We recommend using a `[object] [verb]` format for your event names, where `[object]` is the entity that the behavior relates to, and `[verb]` is the behavior itself. For example, `project created`, `user signed up`, or `invite sent`.
 
-> **Tip:** You can define event schemas with typed properties and generate type-safe code using [schema management](/docs/product-analytics/schema-management.md).
+> **Tip:** You can define event schemas with typed properties and generate type-safe code using [schema management](https://posthog.com/docs/product-analytics/schema-management.md).
 
 ### Setting event properties
 
-Optionally, you can include additional information with the event by including a [properties](/docs/data/events.md#event-properties) object:
-
-Go
+Optionally, you can include additional information with the event by including a [properties](https://posthog.com/docs/data/events.md#event-properties) object:
 
 ```go
 client.Enqueue(posthog.Capture{
@@ -78,8 +88,6 @@ client.Enqueue(posthog.Capture{
 
 If you're aiming for a backend-only implementation of PostHog and won't be capturing events from your frontend, you can send `pageviews` from your backend like so:
 
-Go
-
 ```go
 client.Enqueue(posthog.Capture{
   DistinctId: "distinct_id_of_the_user",
@@ -91,9 +99,7 @@ client.Enqueue(posthog.Capture{
 
 ## Person profiles and properties
 
-For backward compatibility, the Go SDK captures identified events by default. These create [person profiles](/docs/data/persons.md). To set [person properties](/docs/product-analytics/person-properties.md) in these profiles, include them when capturing an event:
-
-Go
+For backward compatibility, the Go SDK captures identified events by default. These create [person profiles](https://posthog.com/docs/data/persons.md). To set [person properties](https://posthog.com/docs/product-analytics/person-properties.md) in these profiles, include them when capturing an event:
 
 ```go
 client.Enqueue(posthog.Capture{
@@ -110,11 +116,9 @@ client.Enqueue(posthog.Capture{
 })
 ```
 
-For more details on the difference between `$set` and `$set_once`, see our [person properties docs](/docs/product-analytics/person-properties.md#what-is-the-difference-between-set-and-set_once).
+For more details on the difference between `$set` and `$set_once`, see our [person properties docs](https://posthog.com/docs/product-analytics/person-properties.md#what-is-the-difference-between-set-and-set_once).
 
-To capture [anonymous events](/docs/data/anonymous-vs-identified-events.md) without person profiles, set the event's `$process_person_profile` property to `false`:
-
-Go
+To capture [anonymous events](https://posthog.com/docs/data/anonymous-vs-identified-events.md) without person profiles, set the event's `$process_person_profile` property to `false`:
 
 ```go
 client.Enqueue(posthog.Capture{
@@ -132,8 +136,6 @@ Sometimes, you want to assign multiple distinct IDs to a single user. This is he
 
 In this case, you can use `alias` to assign another distinct ID to the same user.
 
-Go
-
 ```go
 client.Enqueue(posthog.Alias{
   DistinctId: "distinct_id",
@@ -141,15 +143,13 @@ client.Enqueue(posthog.Alias{
 })
 ```
 
-We strongly recommend reading our docs on [alias](/docs/product-analytics/identify.md#alias-assigning-multiple-distinct-ids-to-the-same-user) to best understand how to correctly use this method.
+We strongly recommend reading our docs on [alias](https://posthog.com/docs/product-analytics/identify.md#alias-assigning-multiple-distinct-ids-to-the-same-user) to best understand how to correctly use this method.
 
 ## Request context
 
 Use request context to apply a distinct ID, session ID, and common request properties to capture and exception events inside a `net/http` request. This is useful when connecting frontend activity to backend events, session replay, error tracking, and feature flag evaluation.
 
-If you're using [PostHog JS](/docs/libraries/js.md) on the frontend, configure [`tracing_headers`](/docs/libraries/js/config.md#tracing-headers) for your Go backend hostname so browser requests include the session and distinct ID headers. Then wrap your handler with `NewRequestContextMiddleware` and use the context-aware helpers:
-
-Go
+If you're using [PostHog JS](https://posthog.com/docs/libraries/js.md) on the frontend, configure [`tracing_headers`](https://posthog.com/docs/libraries/js/config.md#tracing-headers) for your Go backend hostname so browser requests include the session and distinct ID headers. Then wrap your handler with `NewRequestContextMiddleware` and use the context-aware helpers:
 
 ```go
 handler := posthog.NewRequestContextMiddleware(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
@@ -168,12 +168,10 @@ handler := posthog.NewRequestContextMiddleware(http.HandlerFunc(func(w http.Resp
 
 The middleware adds `$current_url`, `$request_method`, `$request_path`, `$user_agent`, and `$ip` properties. By default, it also reads `X-PostHog-Distinct-Id` and `X-PostHog-Session-Id` as request-scoped defaults. Explicit `DistinctId` values and `$session_id` properties passed to captures take precedence over request context.
 
-If request context is attached but no distinct ID is available, capture and exception events are sent as [personless events](/docs/data/anonymous-vs-identified-events.md) with an auto-generated UUID and `$process_person_profile: false`. Calls to `Enqueue` without request context still require `DistinctId`. `EvaluateFlagsWithContext` uses the request-scoped distinct ID when `EvaluateFlagsPayload.DistinctId` is empty, but it never generates personless IDs and returns `ErrNoDistinctID` when no distinct ID is available.
+If request context is attached but no distinct ID is available, capture and exception events are sent as [personless events](https://posthog.com/docs/data/anonymous-vs-identified-events.md) with an auto-generated UUID and `$process_person_profile: false`. Calls to `Enqueue` without request context still require `DistinctId`. `EvaluateFlagsWithContext` uses the request-scoped distinct ID when `EvaluateFlagsPayload.DistinctId` is empty, but it never generates personless IDs and returns `ErrNoDistinctID` when no distinct ID is available.
 
 Tracing headers are client-controlled analytics context, not authentication or authorization. For security-sensitive server-side decisions, pass an authenticated `DistinctId` explicitly or attach one to the request context:
 
-Go
-
 ```go
 ctx := posthog.WithRequestContext(r.Context(), posthog.RequestContext{
     DistinctId: user.ID,
@@ -182,8 +180,6 @@ ctx := posthog.WithRequestContext(r.Context(), posthog.RequestContext{
 
 To ignore tracing headers while keeping request metadata, disable tracing header capture:
 
-Go
-
 ```go
 handler := posthog.NewRequestContextMiddleware(
     next,
@@ -193,7 +189,7 @@ handler := posthog.NewRequestContextMiddleware(
 
 ## Feature flags
 
-PostHog's [feature flags](/docs/feature-flags.md) enable you to safely deploy and roll back new features as well as target specific users and groups with them.
+PostHog's [feature flags](https://posthog.com/docs/feature-flags.md) enable you to safely deploy and roll back new features as well as target specific users and groups with them.
 
 There are two steps to implement feature flags in Go:
 
@@ -203,8 +199,6 @@ Call `client.EvaluateFlags()` once for the user, then read values from the retur
 
 #### Boolean feature flags
 
-Go
-
 ```go
 flags, err := client.EvaluateFlags(posthog.EvaluateFlagsPayload{
     DistinctId: "distinct_id_of_your_user",
@@ -222,8 +216,6 @@ if flags.IsEnabled("flag-key") {
 
 #### Multivariate feature flags
 
-Go
-
 ```go
 flags, err := client.EvaluateFlags(posthog.EvaluateFlagsPayload{
     DistinctId: "distinct_id_of_your_user",
@@ -247,9 +239,9 @@ if enabledVariant == "variant-key" { // replace "variant-key" with the key of yo
 
 ### Step 2: Include feature flag information when capturing events
 
-If you want use your feature flag to breakdown or filter events in your [insights](/docs/product-analytics/insights.md), you'll need to include feature flag information in those events. This ensures that the feature flag value is attributed correctly to the event.
+If you want use your feature flag to breakdown or filter events in your [insights](https://posthog.com/docs/product-analytics/insights.md), you'll need to include feature flag information in those events. This ensures that the feature flag value is attributed correctly to the event.
 
-> **Note:** This step is only required for events captured using our server-side SDKs or [API](/docs/api.md).
+> **Note:** This step is only required for events captured using our server-side SDKs or [API](https://posthog.com/docs/api.md).
 
 There are two methods you can use to include feature flag information in your events:
 
@@ -257,8 +249,6 @@ There are two methods you can use to include feature flag information in your ev
 
 Pass the same `flags` object that you used for branching. This attaches the exact flag values from that evaluation and doesn't make another `/flags` request.
 
-Go
-
 ```go
 flags, err := client.EvaluateFlags(posthog.EvaluateFlagsPayload{
     DistinctId: "distinct_id_of_your_user",
@@ -282,8 +272,6 @@ By default, this attaches every flag in the snapshot using `$feature/<flag-key>`
 
 To reduce event property bloat, pass a filtered snapshot:
 
-Go
-
 ```go
 // Attach only flags accessed with IsEnabled() or GetFlag() before this call
 client.Enqueue(posthog.Capture{
@@ -306,8 +294,6 @@ client.Enqueue(posthog.Capture{
 
 In the event properties, include `$feature/feature_flag_name: variant_key`:
 
-Go
-
 ```go
 client.Enqueue(posthog.Capture{
     DistinctId: "distinct_id_of_your_user",
@@ -321,8 +307,6 @@ client.Enqueue(posthog.Capture{
 
 By default, `EvaluateFlags()` evaluates every flag for the user. If you only need a few flags, pass `FlagKeys` to request only those flags:
 
-Go
-
 ```go
 flags, err := client.EvaluateFlags(posthog.EvaluateFlagsPayload{
     DistinctId: "distinct_id_of_your_user",
@@ -332,7 +316,7 @@ flags, err := client.EvaluateFlags(posthog.EvaluateFlagsPayload{
 
 ### Sending `$feature_flag_called` events
 
-Capturing `$feature_flag_called` events enables PostHog to know when a flag was accessed by a user and provide [analytics and insights](/docs/product-analytics/insights.md) on the flag. With `EvaluateFlags()`, the SDK sends this event when you call `flags.IsEnabled()` or `flags.GetFlag()` for a flag.
+Capturing `$feature_flag_called` events enables PostHog to know when a flag was accessed by a user and provide [analytics and insights](https://posthog.com/docs/product-analytics/insights.md) on the flag. With `EvaluateFlags()`, the SDK sends this event when you call `flags.IsEnabled()` or `flags.GetFlag()` for a flag.
 
 The SDK deduplicates these events per `(distinct_id, flag, value)` in a local cache. If you reinitialize the PostHog client, the cache resets and `$feature_flag_called` events may be sent again. PostHog handles duplicates, so duplicate `$feature_flag_called` events don't affect your analytics.
 
@@ -340,14 +324,12 @@ The SDK deduplicates these events per `(distinct_id, flag, value)` in a local ca
 
 ### Advanced: Overriding server properties
 
-Sometimes, you may want to evaluate feature flags using [person properties](/docs/product-analytics/person-properties.md), [groups](/docs/product-analytics/group-analytics.md), or group properties that haven't been ingested yet, or were set incorrectly earlier.
+Sometimes, you may want to evaluate feature flags using [person properties](https://posthog.com/docs/product-analytics/person-properties.md), [groups](https://posthog.com/docs/product-analytics/group-analytics.md), or group properties that haven't been ingested yet, or were set incorrectly earlier.
 
 You can provide properties to evaluate the flag with by using the `person properties`, `groups`, and `group properties` arguments. PostHog will then use these values to evaluate the flag, instead of any properties currently stored on your PostHog server.
 
 For example:
 
-Go
-
 ```go
 flags, err := client.EvaluateFlags(posthog.EvaluateFlagsPayload{
     DistinctId: "distinct_id_of_the_user",
@@ -403,8 +385,6 @@ Simply include any of these properties in the `person_properties` parameter alon
 
 You can configure the `FeatureFlagRequestTimeout` parameter when initializing your PostHog client to set a flag request timeout. This helps prevent your code from being blocked if PostHog's servers are too slow to respond. By default, this is set to 3 seconds.
 
-Go
-
 ```go
 // import "time"
 
@@ -424,13 +404,11 @@ Evaluating feature flags requires making a request to PostHog for each flag. How
 
 It is best practice to use local evaluation flags when possible, since this enables you to resolve flags faster and with fewer API calls.
 
-For details on how to implement local evaluation, see our [local evaluation guide](/docs/feature-flags/local-evaluation.md).
+For details on how to implement local evaluation, see our [local evaluation guide](https://posthog.com/docs/feature-flags/local-evaluation.md).
 
 ## Experiments (A/B tests)
 
-Since [experiments](/docs/experiments/start-here.md) use feature flags, the code for running an experiment is very similar to the feature flags code:
-
-Go
+Since [experiments](https://posthog.com/docs/experiments/start-here.md) use feature flags, the code for running an experiment is very similar to the feature flags code:
 
 ```go
 flags, err := client.EvaluateFlags(posthog.EvaluateFlagsPayload{
@@ -446,7 +424,7 @@ if variant == "variant-name" {
 }
 ```
 
-It's also possible to [run experiments without using feature flags](/docs/experiments/running-experiments-without-feature-flags.md).
+It's also possible to [run experiments without using feature flags](https://posthog.com/docs/experiments/running-experiments-without-feature-flags.md).
 
 ## Error tracking
 
@@ -454,8 +432,6 @@ You can capture exceptions and errors using the Go SDK. There are two approaches
 
 **Direct capture** using `NewDefaultException`, which automatically generates a stack trace:
 
-Go
-
 ```go
 exception := posthog.NewDefaultException(
     time.Now(),
@@ -468,8 +444,6 @@ client.Enqueue(exception)
 
 **Automatic capture** using the `SlogCaptureHandler`, which wraps Go's `log/slog` and sends log records at warning level and above as exceptions:
 
-Go
-
 ```go
 baseHandler := slog.NewTextHandler(os.Stdout, &slog.HandlerOptions{
     Level: slog.LevelInfo,
@@ -484,18 +458,16 @@ logger := slog.New(posthog.NewSlogCaptureHandler(baseHandler, client,
 logger.Warn("Something broke", "error", fmt.Errorf("connection refused"))
 ```
 
-For the full setup guide, see the [Go error tracking installation docs](/docs/error-tracking/installation/go.md).
+For the full setup guide, see the [Go error tracking installation docs](https://posthog.com/docs/error-tracking/installation/go.md).
 
 ## Group analytics
 
-Group analytics allows you to associate an event with a group (e.g. teams, organizations, etc.). Read the [Group Analytics](/docs/user-guides/group-analytics.md) guide for more information.
+Group analytics allows you to associate an event with a group (e.g. teams, organizations, etc.). Read the [Group Analytics](https://posthog.com/docs/user-guides/group-analytics.md) guide for more information.
 
-> **Note:** This is a paid feature and is not available on the open-source or free cloud plan. Learn more on the [pricing page](/pricing.md).
+> **Note:** This is a paid feature and is not available on the open-source or free cloud plan. Learn more on the [pricing page](https://posthog.com/pricing.md).
 
 -   Send an event associated with a group
 
-Go
-
 ```go
 client.Enqueue(posthog.Capture{
     DistinctId: "user_distinct_id",
@@ -507,8 +479,6 @@ client.Enqueue(posthog.Capture{
 
 -   Update properties on a group
 
-Go
-
 ```go
 client.Enqueue(posthog.GroupIdentify{
     Type: "company",
@@ -524,11 +494,3 @@ The `name` is a special property which is used in the PostHog UI for the name of
 ## Thank you
 
 This library is largely based on the `analytics-go` package.
-
-### Still have questions?
-
-Ask PostHog AI
-
-### Was this page useful?
-
-HelpfulCould be better

package/dist/global-skills/instrument-product-analytics/references/identify-users.md

@@ -2,11 +2,21 @@
 
 # Identify users
 
+Canonical URL: https://posthog.com/docs/getting-started/identify-users
+
+> **Cloud region:** This page uses US Cloud hosts. For an EU Cloud project, use `https://eu.i.posthog.com` instead of `https://us.i.posthog.com` (ingestion host).
+
+## On this page
+
+- [How identify works](#how-identify-works)
+- [Best practices when using identify](#best-practices-when-using-identify)
+- [Further reading](#further-reading)
+
 Linking events to specific users enables you to build a full picture of how they're using your product across different sessions, devices, and platforms.
 
-This is straightforward to do when [capturing backend events](/docs/product-analytics/capture-events?tab=Node.js.md), as you associate events to a specific user using a `distinct_id`, which is a required argument.
+This is straightforward to do when [capturing backend events](https://posthog.com/docs/product-analytics/capture-events?tab=Node.js.md), as you associate events to a specific user using a `distinct_id`, which is a required argument.
 
-However, in the frontend of a [web](/docs/libraries/js/usage.md#capturing-events) or [mobile app](/docs/libraries/ios.md#capturing-events), a `distinct_id` is not a required argument — PostHog's SDKs will generate an anonymous `distinct_id` for you automatically and you can capture events anonymously, provided you use the appropriate [configuration](/docs/libraries/js/usage.md#capturing-anonymous-events).
+However, in the frontend of a [web](https://posthog.com/docs/libraries/js/usage.md#capturing-events) or [mobile app](https://posthog.com/docs/libraries/ios.md#capturing-events), a `distinct_id` is not a required argument — PostHog's SDKs will generate an anonymous `distinct_id` for you automatically and you can capture events anonymously, provided you use the appropriate [configuration](https://posthog.com/docs/libraries/js/usage.md#capturing-anonymous-events).
 
 To link events to specific users, call `identify`:
 
@@ -68,7 +78,7 @@ Due to the cost of processing them, anonymous events can be up to 4x cheaper tha
 
 When a user starts browsing your website or app, PostHog automatically assigns them an **anonymous ID**, which is stored locally.
 
-Provided you've [configured persistence](/docs/libraries/js/persistence.md) to use cookies or `localStorage`, this enables us to track anonymous users – even across different sessions.
+Provided you've [configured persistence](https://posthog.com/docs/libraries/js/persistence.md) to use cookies or `localStorage`, this enables us to track anonymous users – even across different sessions.
 
 By calling `identify` with a `distinct_id` of your choice (usually the user's ID in your database, or their email), you link the anonymous ID and distinct ID together.
 
@@ -76,7 +86,7 @@ Thus, all past and future events made with that anonymous ID are now associated
 
 This enables you to do things like associate events with a user from before they log in for the first time, or associate their events across different devices or platforms.
 
-Using identify in the backend
+**Using identify in the backend**
 
 Although you can call `identify` using our backend SDKs, it is used most in frontends. This is because there is no concept of anonymous sessions in the backend SDKs, so calling `identify` only updates person profiles.
 
@@ -96,9 +106,7 @@ If you call `identify` multiple times with the same data without reloading the p
 
 #### Identify users when the web SDK loads
 
-If your app already knows the signed-in user when you initialize the JavaScript web SDK, the [`loaded` callback](/docs/libraries/js/config.md) is a convenient place to call `identify`. This identifies the user as soon as the SDK has loaded:
-
-Web
+If your app already knows the signed-in user when you initialize the JavaScript web SDK, the [`loaded` callback](https://posthog.com/docs/libraries/js/config.md) is a convenient place to call `identify`. This identifies the user as soon as the SDK has loaded:
 
 ```javascript
 posthog.init('<ph_project_token>', {
@@ -168,8 +176,6 @@ await Posthog().reset();
 
 If you *also* want to reset the `device_id` so that the device will be considered a new device in future events, you can pass `true` as an argument:
 
-Web
-
 ```javascript
 posthog.reset(true)
 ```
@@ -178,17 +184,17 @@ posthog.reset(true)
 
 You'll notice that one of the parameters in the `identify` method is a `properties` object.
 
-This enables you to set [person properties](/docs/product-analytics/person-properties.md).
+This enables you to set [person properties](https://posthog.com/docs/product-analytics/person-properties.md).
 
 Whenever possible, we recommend passing in all person properties you have available each time you call identify, as this ensures their person profile on PostHog is up to date.
 
 Person properties can also be set being adding a `$set` property to a event `capture` call.
 
-**\`$set\` and \`$set\_once\` aren't stored on events**
+**`$set` and `$set_once` aren't stored on events**
 
-These properties only tell PostHog how to update person data during ingestion — they aren't kept on the stored event, so you can't filter, break down, or query events by them. To query the values you set, use [person properties](/docs/product-analytics/person-properties.md) instead.
+These properties only tell PostHog how to update person data during ingestion — they aren't kept on the stored event, so you can't filter, break down, or query events by them. To query the values you set, use [person properties](https://posthog.com/docs/product-analytics/person-properties.md) instead.
 
-See our [person properties docs](/docs/product-analytics/person-properties.md) for more details on how to work with them and best practices.
+See our [person properties docs](https://posthog.com/docs/product-analytics/person-properties.md) for more details on how to work with them and best practices.
 
 ### 5\. Use deep links between platforms
 
@@ -206,8 +212,8 @@ In these cases, you can use a [deep link](https://developer.android.com/training
 2.  Add the distinct ID to the deep link as query parameters, along with other properties like UTM parameters.
 3.  When the user is redirected to the app, parse the deep link and handle the following cases:
 
--   The mobile app is already authenticated. In this case, call [`posthog.alias()`](/docs/libraries/js/usage.md#alias) with the distinct ID from the web. This associates the two distinct IDs as a single person.
--   The mobile app is unauthenticated. In this case, call [`posthog.identify()`](/docs/libraries/js/usage.md#identifying-users) with the distinct ID from the web so pre-login mobile events stay connected to the web session. When the user later logs in on mobile, call `identify()` again with your canonical user ID.
+-   The mobile app is already authenticated. In this case, call [`posthog.alias()`](https://posthog.com/docs/libraries/js/usage.md#alias) with the distinct ID from the web. This associates the two distinct IDs as a single person.
+-   The mobile app is unauthenticated. In this case, call [`posthog.identify()`](https://posthog.com/docs/libraries/js/usage.md#identifying-users) with the distinct ID from the web so pre-login mobile events stay connected to the web session. When the user later logs in on mobile, call `identify()` again with your canonical user ID.
 
 As long as you associate the distinct IDs with `posthog.identify()` or `posthog.alias()`, you can track events generated across platforms.
 
@@ -294,14 +300,6 @@ object DeepLinkIdentityManager {
 
 ## Further reading
 
--   [Identifying users docs](/docs/product-analytics/identify.md)
--   [How person processing works](/docs/how-posthog-works/ingestion-pipeline.md#2-person-processing)
--   [An introductory guide to identifying users in PostHog](/tutorials/identifying-users-guide.md)
-
-### Still have questions?
-
-Ask PostHog AI
-
-### Was this page useful?
-
-HelpfulCould be better
+-   [Identifying users docs](https://posthog.com/docs/product-analytics/identify.md)
+-   [How person processing works](https://posthog.com/docs/how-posthog-works/ingestion-pipeline.md#2-person-processing)
+-   [An introductory guide to identifying users in PostHog](https://posthog.com/tutorials/identifying-users-guide.md)

package/dist/global-skills/instrument-product-analytics/references/ios.md

@@ -2,9 +2,21 @@
 
 # iOS
 
+Canonical URL: https://posthog.com/docs/libraries/ios
+
+## On this page
+
+- [Installation](#installation)
+- [Identifying users](#identifying-users)
+- [Offline behavior](#offline-behavior)
+- [Using PostHog with application extensions](#using-posthog-with-application-extensions)
+- [Method swizzling](#method-swizzling)
+- [Push notifications](#push-notifications)
+- [Next steps](#next-steps)
+
 The PostHog iOS SDK is a library that you can use to track events, identify users, record session replays, evaluate feature flags, run experiments, build surveys, and more.
 
-This page shows you how to install the SDK and get started with it. If you've already installed the SDK, you can skip ahead to learn about [using the features](/docs/libraries/ios/usage.md) and [configuring the SDK](/docs/libraries/ios/configuration.md).
+This page shows you how to install the SDK and get started with it. If you've already installed the SDK, you can skip ahead to learn about [using the features](https://posthog.com/docs/libraries/ios/usage.md) and [configuring the SDK](https://posthog.com/docs/libraries/ios/configuration.md).
 
 ## Installation
 
@@ -46,12 +58,10 @@ Package.swift
 
 Configuration is done through the `PostHogConfig` object. Here's a basic configuration example to get you started.
 
-You can find more advanced configuration options in the [configuration page](/docs/libraries/ios/configuration.md).
+You can find more advanced configuration options in the [configuration page](https://posthog.com/docs/libraries/ios/configuration.md).
 
 ## UIKit
 
-Swift
-
 ```swift
 import Foundation
 import PostHog
@@ -73,8 +83,6 @@ class AppDelegate: NSObject, UIApplicationDelegate {
 
 ## SwiftUI
 
-Swift
-
 ```swift
 import SwiftUI
 import PostHog
@@ -106,13 +114,13 @@ struct YourGreatApp: App {
 
 ## Identifying users
 
-> **Identifying users is required.** Call `posthog.identify('your-user-id')` after login to link events to a known user. This is what connects frontend event captures, [session replays](/docs/session-replay.md), [LLM traces](/docs/ai-engineering.md), and [error tracking](/docs/error-tracking.md) to the same person — and lets backend events link back too.
+> **Identifying users is required.** Call `posthog.identify('your-user-id')` after login to link events to a known user. This is what connects frontend event captures, [session replays](https://posthog.com/docs/session-replay.md), [LLM traces](https://posthog.com/docs/ai-engineering.md), and [error tracking](https://posthog.com/docs/error-tracking.md) to the same person — and lets backend events link back too.
 >
 > Use a stable ID from your auth system when possible, not an email or display name. Send those as person properties instead. If your app has no other stable key, email works as a fallback if they are unique. Never a shared literal like `"anonymous"` or `"user"`, which pools many people onto one person and corrupts their data. When no ID is available at all, skip the identify and retain the anonymous distinct ID that's automatically assigned.
 >
 > Call `posthog.reset()` on logout, so the next person to use the browser doesn't inherit the last one's identity.
 >
-> See our guide on [identifying users](/docs/getting-started/identify-users.md) for how to set this up.
+> See our guide on [identifying users](https://posthog.com/docs/getting-started/identify-users.md) for how to set this up.
 
 ## Offline behavior
 
@@ -122,7 +130,7 @@ The PostHog iOS SDK will continue to capture events when the device is offline.
 -   When the queue is full, the oldest event is deleted first.
 -   The queue is flushed only when the device is online.
 
-You can find the options for configuring the offline behavior in the [configuration page](/docs/libraries/ios/configuration.md#all-configuration-options).
+You can find the options for configuring the offline behavior in the [configuration page](https://posthog.com/docs/libraries/ios/configuration.md#all-configuration-options).
 
 ## Using PostHog with application extensions
 
@@ -134,7 +142,7 @@ By default, each iOS app target stores its data in its own sandboxed directory.
 -   Fragmented user journeys
 -   Difficulty tracking feature adoption across your app ecosystem
 
-[Learn more about setting up app groups](/docs/libraries/ios/configuration.md#setting-up-app-groups).
+[Learn more about setting up app groups](https://posthog.com/docs/libraries/ios/configuration.md#setting-up-app-groups).
 
 ## Method swizzling
 
@@ -142,23 +150,15 @@ The PostHog iOS SDK uses method swizzling to intercept and modify method calls a
 
 Method swizzling is particularly important for accurate session metrics tracking. When disabled, the SDK cannot capture optimal session metrics.
 
-You can learn more about configuring method swizzling in the [configuration page](/docs/libraries/ios/configuration.md#method-swizzling).
+You can learn more about configuring method swizzling in the [configuration page](https://posthog.com/docs/libraries/ios/configuration.md#method-swizzling).
 
 ## Push notifications
 
-The iOS SDK can register a device for [Workflows](/docs/workflows.md) push notifications and capture when a user opens one. For setup, including automatic and manual registration, capturing opens, and identity verification, see [Push notifications](/docs/workflows/push-notifications.md).
+The iOS SDK can register a device for [Workflows](https://posthog.com/docs/workflows.md) push notifications and capture when a user opens one. For setup, including automatic and manual registration, capturing opens, and identity verification, see [Push notifications](https://posthog.com/docs/workflows/push-notifications.md).
 
 ## Next steps
 
 Now that you've installed the SDK, explore the configuration and usage options:
 
--   [Learn about using all of the features of PostHog with iOS SDK](/docs/libraries/ios/usage.md)
--   [Learn about configuration options for the iOS SDK](/docs/libraries/ios/configuration.md)
-
-### Still have questions?
-
-Ask PostHog AI
-
-### Was this page useful?
-
-HelpfulCould be better
+-   [Learn about using all of the features of PostHog with iOS SDK](https://posthog.com/docs/libraries/ios/usage.md)
+-   [Learn about configuration options for the iOS SDK](https://posthog.com/docs/libraries/ios/configuration.md)

package/dist/global-skills/instrument-product-analytics/references/laravel.md

@@ -2,11 +2,23 @@
 
 # Laravel
 
-PostHog integrates with Laravel through the [PostHog PHP SDK](/docs/libraries/php.md). This page covers Laravel-specific setup. For SDK features such as event capture, identifying users, feature flags, group analytics, and configuration options, see the [PHP SDK docs](/docs/libraries/php.md).
+Canonical URL: https://posthog.com/docs/libraries/laravel
+
+> **Cloud region:** This page uses US Cloud hosts. For an EU Cloud project, use `https://eu.i.posthog.com` instead of `https://us.i.posthog.com` (ingestion host).
+
+## On this page
+
+- [Installation](#installation)
+- [Request context middleware](#request-context-middleware)
+- [Error tracking in Laravel](#error-tracking-in-laravel)
+- [Long-running processes](#long-running-processes)
+- [Next steps](#next-steps)
+
+PostHog integrates with Laravel through the [PostHog PHP SDK](https://posthog.com/docs/libraries/php.md). This page covers Laravel-specific setup. For SDK features such as event capture, identifying users, feature flags, group analytics, and configuration options, see the [PHP SDK docs](https://posthog.com/docs/libraries/php.md).
 
 ## Installation
 
-Install the PHP SDK as described in the [PHP installation guide](/docs/libraries/php.md#installation), then add your project token and host to `.env`:
+Install the PHP SDK as described in the [PHP installation guide](https://posthog.com/docs/libraries/php.md#installation), then add your project token and host to `.env`:
 
 .env
 
@@ -58,9 +70,9 @@ class AppServiceProvider extends ServiceProvider
 
 ## Request context middleware
 
-Client SDKs such as [PostHog JS](/docs/libraries/js.md) can send tracing headers to your Laravel backend. Configure [`tracing_headers`](/docs/libraries/js/config.md#tracing-headers) for your Laravel backend hostname so browser requests include the session and distinct ID headers.
+Client SDKs such as [PostHog JS](https://posthog.com/docs/libraries/js.md) can send tracing headers to your Laravel backend. Configure [`tracing_headers`](https://posthog.com/docs/libraries/js/config.md#tracing-headers) for your Laravel backend hostname so browser requests include the session and distinct ID headers.
 
-The PHP SDK can read `X-PostHog-Distinct-Id` and `X-PostHog-Session-Id` headers and apply them to events captured during the request. Tracing headers are client-controlled analytics context, not authentication or authorization. For security-sensitive server-side events or decisions, pass an authenticated `distinctId` explicitly, such as `auth()->id()`. For the lower-level context APIs, see the [PHP request context docs](/docs/libraries/php.md#request-context).
+The PHP SDK can read `X-PostHog-Distinct-Id` and `X-PostHog-Session-Id` headers and apply them to events captured during the request. Tracing headers are client-controlled analytics context, not authentication or authorization. For security-sensitive server-side events or decisions, pass an authenticated `distinctId` explicitly, such as `auth()->id()`. For the lower-level context APIs, see the [PHP request context docs](https://posthog.com/docs/libraries/php.md#request-context).
 
 Add middleware like this:
 
@@ -110,7 +122,7 @@ Register this middleware using your Laravel version's normal middleware registra
 
 ## Error tracking in Laravel
 
-The PHP SDK supports [error tracking](/docs/libraries/php.md#error-tracking), but Laravel handles most request exceptions before they become uncaught PHP exceptions. Capture Laravel-reported exceptions explicitly.
+The PHP SDK supports [error tracking](https://posthog.com/docs/libraries/php.md#error-tracking), but Laravel handles most request exceptions before they become uncaught PHP exceptions. Capture Laravel-reported exceptions explicitly.
 
 In Laravel 11 and later, add a report callback in `bootstrap/app.php`:
 
@@ -147,8 +159,6 @@ In normal PHP request lifecycles, queued events flush when the client is destroy
 
 If you prefer immediate delivery in queue workers, configure the PHP SDK with `batch_size` set to `1` for those workers:
 
-PHP
-
 ```php
 PostHog::init(
     '<ph_project_token>',
@@ -161,12 +171,4 @@ PostHog::init(
 
 ## Next steps
 
-See the [PHP SDK docs](/docs/libraries/php.md) for usage examples and the full API reference.
-
-### Still have questions?
-
-Ask PostHog AI
-
-### Was this page useful?
-
-HelpfulCould be better
+See the [PHP SDK docs](https://posthog.com/docs/libraries/php.md) for usage examples and the full API reference.