# How to use PostHog with Replicas Connect PostHog to Replicas, write a focused investigation task, and review the pull request or technical report the agent returns. - Author: Replicas Team - Published: 2026-08-13 - Category: Best practices - Canonical: https://tryreplicas.com/blog/how-to-use-posthog-with-replicas Which release dropped onboarding completion from 79% to 62%? PostHog shows you the drop and the session recordings behind it. The answer is in the codebase. Replicas works across both: connect it to PostHog and a repository, hand it a bounded question, and it reads the funnel, traces the flow into the code, and opens a pull request. When the evidence does not support a change, it writes up what it found instead. This guide covers the setup, the task format that works, and how to review what comes back. ## What can Replicas access? After you connect PostHog, Replicas can access the projects, events, insights, dashboards, feature flags, and recordings available to that account. The agent also needs access to the repository and a configured environment. PostHog provides the product evidence. The repository provides the implementation, and the environment gives the agent a way to run the application and verify its work. ## Summary - Connect PostHog with the narrowest account access that covers the task. - Choose one product behavior to investigate. - Specify the project, cohort, time range, and relevant PostHog data. - Name the repository and product area to inspect. - Ask for a pull request or a technical report. - Require the agent to show its evidence and run the relevant checks. ## 1. Connect PostHog Install the PostHog plugin from [Personal Integrations](https://tryreplicas.com/dashboard/account/integrations) or [Organization Integrations](https://tryreplicas.com/dashboard/integrations). If both are installed, Replicas uses the personal connection. Create a personal API key in PostHog under **Settings → Personal API keys**, then select the region that matches your US or EU Cloud account. Use an account with only the access needed for the work you plan to assign. See the [plugin setup documentation](https://docs.tryreplicas.com/features/plugins) for the full connection flow. ## 2. Set up the repository Bind a Replicas environment to the repository the agent should inspect. Add the variables, files, and setup commands needed to run the relevant part of the application. Before assigning the task, confirm that the workspace can: - install dependencies and run code generation; - start the relevant application or service; - run the typecheck and tests; - open the product flow in a browser when visual verification is required. Use the [Replicas quickstart](https://docs.tryreplicas.com/quickstart) for the initial setup and the [environment documentation](https://docs.tryreplicas.com/features/environments) for repository-specific configuration. ## 3. Write a focused task Include the behavior, scope, code area, expected output, and verification steps in the first message. **Good example** ```text Investigate the drop in repository-connection completion for new organizations during the last seven days. Use the onboarding funnel and recordings for sessions that reached the connection step but did not complete it. Trace the flow through the onboarding route and OAuth callback. If one reproducible defect explains the behavior, fix it, run the onboarding browser flow and typecheck, and open a pull request. Otherwise, return a report with the PostHog evidence and the code paths you inspected. ``` **Poor example** ```text Analyze our PostHog account and improve conversion. ``` The poor example does not define the behavior, data scope, repository, or deliverable. The agent has no clear stopping condition and cannot tell whether a code change is justified. Use this template: ```text Investigate [product behavior] in PostHog project [project] for [cohort and time range]. Inspect [insight, funnel, flag, events, or recordings] and trace the behavior to [repository or product area]. If the evidence supports a specific code change, implement it, run [verification], and open a pull request. Otherwise, return a technical report with the evidence, relevant code paths, competing explanations, and the next information needed. Do not infer causality that the available evidence does not support. ``` ## 4. Check the product and the instrumentation A metric can move because the product changed or because its measurement changed. Ask the agent to inspect both before editing the application. For event-based investigations, check: - where each event is emitted; - whether event names or properties changed during the selected time range; - whether duplicate, missing, or delayed events affect the result; - whether a feature flag or experiment changed the path users followed; - whether recordings support the same explanation as the aggregate data. If the event is wrong, fix the instrumentation. If the data supports several explanations, return a report that lists them and identifies the evidence needed to choose between them. ## 5. Choose the output Ask for a pull request when the evidence supports a specific, reproducible code change. The pull request should include: - the PostHog signal and scope; - the root cause supported by that evidence; - the relevant routes, components, handlers, events, or flag logic; - the code change; - the commands and product flow used for verification. Ask for a technical report when the agent cannot make a safe change. The report should include the same evidence and code paths, plus the reason no change was made. That may be insufficient recordings, ambiguous cohort behavior, a state the agent could not reproduce, or a product decision that needs an owner. ## 6. Review the result Check that the selected PostHog data supports the stated root cause. The code change should address that cause, and the verification should cover the affected product flow. Review analytics events and feature-flag logic closely. A small change to either can alter future measurements even when the product behaves the same way. Replicas keeps the investigation, files, commands, and pull request in the workspace so you can review how the agent reached its result. ## Good tasks for this workflow - Investigate a conversion change after a release. - Trace repeated clicks or abandoned sessions to a UI state. - Audit missing or inconsistent analytics events. - Inspect an experiment result and remove a losing feature-flag branch. - Reproduce a behavior seen in recordings. - Identify the code paths responsible for a cohort-specific issue. [Start a Replicas workspace](https://tryreplicas.com/auth?mode=signup), [configure the PostHog plugin](https://docs.tryreplicas.com/features/plugins), or review the [PostHog use-case page](/use-cases/posthog-ai-product-engineer).