Product analytics RFP questions for vendors

Product analytics RFP questions to ask before you choose a platform

A team that needs event tracking, funnels and session replay kept inside its own infrastructure should compare PostHog, OpenReplay and Umami on identical terms, and the simplest way to do that is one written brief sent to every vendor and implementation partner. Use the same questions, the same data volumes and the same deadline for each respondent, and require written answers. Verbal demos are useful for seeing the product, but they do not create a record you can hold a supplier to after signature. Ask each party to state its answers as commitments, and keep a single comparison sheet so that gaps show up quickly.

The platforms differ in ways that change what you are buying. PostHog's MIT-licensed repository excludes the ee/ directory, and its README says premium features there need a PostHog license on a self-hosted instance. OpenReplay's monorepo is mostly AGPLv3 with an ee/ directory under a commercial license, and its Enterprise edition adds SSO, SCIM and audit trail on custom terms. Umami is MIT licensed, but its self-hosted build lacks features that Umami Cloud offers, such as email reports and a streaming API. Ask each vendor to list exactly which features in your requirements sit in the free edition, which sit in a paid edition and which sit in a platform package, and to put the license obligation for each in writing.

Your implementation partner's answers matter as much as the platform's. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not provide customer support for infrastructure questions on self-hosted instances, so someone else must own upgrades, backups, incident response and the migration of historical data. Ask partners to name who performs each of those tasks, how the fixed scope is written, what happens after go-live, and which support terms are offered as a separate retainer. Confirm the answers with the vendor's own documentation.

Which platform and edition fit the brief

PostHog covers product analytics, session replay, feature flags, experiments, surveys and data pipelines, and its repository is MIT licensed except for the content in the ee/ directory. Anything in ee/ is covered by a separate license, and premium features from that directory on a self-hosted instance require a PostHog license. The brief should therefore separate the functions you need from the edition that includes them, and ask the vendor to map each function to either the open-source core or the licensed code.

Edition boundary: Ask which features you need (SSO, audit logs, custom roles, project permissions) sit in ee/ and what license covers them on your instance.
Free software option: If your policy requires fully free software, ask the vendor to confirm how the posthog-foss repository differs from the main repository and which features it omits.
Self-hosted versus Cloud gaps: Request a written comparison of features available only on PostHog Cloud, including the hosting regions offered there.
Support model: Ask for the written support terms, since PostHog's self-host documentation states that self-hosted deployments are officially unsupported.
Scale limits: Ask the vendor to confirm the event volume it considers suitable for open-source deployments and the point at which it recommends moving to Cloud.

Confirm every item in writing with the vendor, because the licence and support position determines what your implementation partner can legally and practically deliver.

Questions to put in the RFP, grouped by area

Which edition of PostHog, OpenReplay or Umami should we name in the RFP?

Name the exact product, edition and licence you are buying, and ask each bidder to confirm it in writing. Community and enterprise editions differ: PostHog's premium features in the ee directory need a PostHog license on a self-hosted instance, and OpenReplay's ee directory is under a separate commercial license. Umami is MIT licensed and self-hosted for free, but its Cloud plans add features the self-hosted version lacks, such as email reports and a streaming API. A good answer lists which features you need, marks which edition provides each one, and states whether any requirement depends on a paid package. Ask for the feature matrix the bidder used, not a general claim that the product 'supports' a capability.

What licence obligations apply to our self-hosted analytics stack?

Ask the bidder to cite the licence file for each component and explain what you must do to comply. PostHog's repository is MIT except the ee directory, covered by ee/LICENSE. OpenReplay's monorepo is mostly AGPLv3, some directories are MIT, and the ee directory is commercial. Umami is MIT. AGPLv3 can carry source-availability duties if you modify the software and make it available to users over a network, so ask whether any modifications are planned and how they will be tracked. A strong answer names each licence file, lists the paid components, and states who holds the licence for any commercial part and how it renews. Confirm this with your legal team, since the bidder does not give legal advice.

How will historical data from our current analytics tool be migrated?

Ask for a written migration plan with stated limits, not a promise to import everything. PostHog's managed migrations can pull historical events from Mixpanel or Amplitude with API credentials, or from JSONL files in an S3 bucket. Each direct import job covers at most one year of data, events are not deduplicated, and once imported there is no way to selectively delete event data. Historical imports are free of ingestion fees when sent with the historical_migration flag, but a paid product analytics plan is required to unlock the import features. A good answer lists the source tools, the date range per job, the deduplication approach, the deletion procedure, and the cost of any paid plan the migration depends on.

What hosting model and infrastructure sizing does the bidder recommend?

Ask which hosting model fits your data location and event volume, and what sizing it assumes. PostHog's self-host documentation offers a free Docker Compose hobby deployment and recommends a server equivalent to 4 vCPU, 16 GB of RAM and more than 30 GB of storage, and its README says open-source deployments should scale to about 100k events per month before moving to PostHog Cloud. OpenReplay's README says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start, and lists AWS, Google Cloud, Azure, DigitalOcean, Scaleway, OVHcloud, Kubernetes with Helm, Docker and Ubuntu as targets. Ask the bidder to state the expected event volume, the storage growth per month, the region and the backup location, and to explain how sizing changes at higher volumes.

What security evidence can the bidder provide for capture, storage and access?

Ask for evidence you can check, not a general statement about security. Relevant items include a written data flow diagram showing what leaves the browser or app, a masking test report for the masking rules, the access control configuration for projects and roles, audit logging settings, and the encryption settings for data at rest and in transit. OpenReplay describes capture-time sanitization that masks or skips data before it reaches the server, input redaction, and a private mode that masks all text and inputs by default. Ask the bidder to show the configuration and a test result that proves masking holds after front-end releases. Also ask which items are only available in a paid edition, such as SSO, SAML, SCIM and audit trail.

Who supports the platform after go-live, and what is covered?

Ask who answers production incidents, under what terms, and who pays for each. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for self-hosted instances. OpenReplay's open-source edition is community supported with self-managed retention, while its Enterprise edition adds a custom SLA and dedicated support on multi-year contracts. A good answer names the vendor's support tier, the partner's retainer scope if one is used, the response targets in writing, who applies upgrades and security patches, and who restores backups. Ask for the support terms as a signed document, not a link.

How is the fixed scope and its change control defined in the contract?

Ask for a written scope that lists deliverables, environments, integrations, number of sites or apps, event tracking plan size, timelines and acceptance criteria. DeployOpen works on fixed-scope engagements agreed in writing before work starts, so the same discipline should appear in any bid you compare. Ask each bidder to state what is excluded, such as custom SDK work, mobile SDK instrumentation, data warehouse pipelines or ongoing testing, and how a change request is priced and approved. A strong answer names the responsibilities of your team and the partner's team in a table, lists the handover documents, and states how the work is accepted. DeployOpen does not publish a price list, so ask for a quote that follows from the written scope.

Can our internal team run the platform alone, and what staff time should we expect?

Ask the bidder to list the operational tasks, the skills needed, and the hours your staff will spend each month after go-live. Typical tasks include upgrades, database backups, certificate renewal, monitoring, retention jobs, access reviews and dashboard maintenance. Compare the open-source route with the managed route: PostHog Cloud, OpenReplay Dedicated and Umami Cloud move these tasks to the vendor but carry their own subscription prices, such as Umami Cloud Pro at $20 per month for 1 million events, as published on its pricing page. Ask for the staff time estimate in writing, the named owner for each task, and the cost of retainers or training if your team cannot run the stack without help.

How licence boundaries and historical data change the answers

Ask every bidder which licence covers the exact code you will run. PostHog's repository is under the MIT Expat license, but content in the ee/ directory falls under a separate license in ee/LICENSE, and the PostHog README says that using premium features from that directory on a self-hosted instance requires a PostHog license. OpenReplay is split the same way: most of the monorepo is AGPLv3, some directories are MIT, and everything under ee/ is under a separate commercial license. Umami is MIT. Ask the partner to list, in writing, which features in your design sit in an ee/ directory, what each one costs to license, and whether the design still works if you stay on the fully free code. For PostHog, the README points teams that need fully free software to the posthog-foss repository, so confirm whether that fork meets your requirement before you commit to it.

Ask how historical data moves and what cannot be undone. PostHog's managed migrations can import historical events from Mixpanel or Amplitude using API credentials, or from JSONL files in an S3 bucket. Each direct import job covers at most one year of data, and events are not deduplicated, so overlapping jobs or a re-run can double-count. PostHog's migration documentation also says there is no way to selectively delete event data once it is imported, and that a paid product analytics plan is required to unlock the import features, even though historical imports are free of ingestion fees when sent with the historical_migration flag. Ask the partner to state in writing how many jobs your history needs, how they will prevent duplicate events, how they will test a sample before a full load, and who pays for the plan that unlocks imports. Ask what the fallback is if an import is wrong, since a bad import cannot be surgically removed.

Hosting and security evidence to request

Hosting and security answers decide whether a self-hosted analytics or replay platform can hold behavioral data in your environment. Ask each vendor or partner for documents and test results you can check, not general assurances. DeployOpen prepares controls and evidence for your assessments, but independent auditors and certification bodies issue any audit report or certification.

Hosting model and support status

Ask which deployment model each option supports: self-hosted open source, a managed dedicated instance, or bring-your-own-cloud in your own account. PostHog's self-host documentation says self-hosted deployments are officially unsupported and that PostHog does not offer customer support for infrastructure questions on self-hosted instances. Ask who patches, upgrades and answers incidents in each model, and get that split in writing. Also confirm whether a Kubernetes deployment is supported for the paid edition.

Capture-time masking and private mode

Request the masking design, not just a feature name. Ask how the SDK masks or skips data in the browser before it reaches the server, how selectors are configured, and whether a private mode masks all text and inputs by default. OpenReplay's README describes capture-time sanitization and a private mode of this kind. Ask for a written test plan showing that masking still holds after front-end releases, and for a sample of masked recordings from a staging environment.

Access control and SSO by edition

Single sign-on, audit trails, custom roles and SCIM provisioning are often sold as higher-tier or enterprise features. PostHog's pricing page says SSO, audit logs, custom roles and project permissions are sold as platform packages. OpenReplay's pricing lists SSO, SAML, SCIM, roles and audit trail under its self-hosted Enterprise edition. Ask each vendor to map every access control requirement to a specific edition, and confirm which edition your licence covers before you sign.

Data residency and third-party transfers

Ask for a data flow diagram that shows where events, recordings, backups and logs are stored, and which third parties receive any data. Self-hosting keeps session data in your infrastructure, but SDKs, CDNs, email relays and error tools may still transfer data. Request the list of outbound calls the client makes, and the region of every component the platform depends on. Confirm which features send data to a vendor cloud service, such as hosted AI or update checks, and how each can be disabled.

Retention controls and deletion

Ask how retention is set for events and recordings, whether it can differ by project, and how a deletion request is carried out across storage, caches and backups. PostHog's migration documentation says imported event data cannot be selectively deleted, so ask for the same guarantee on every import path. Request the retention settings export and a documented procedure for purging a single user's recordings. Confirm how the vendor describes self-managed retention on each edition.

Penetration test and hardening evidence

Ask for the most recent penetration test summary, scope and remediation status, plus the hardening guide for the version you will run. Confirm whether the vendor publishes security advisories, how patches are delivered, and how quickly critical fixes reach self-hosted installs. Ask whether a partner will run its own test against your deployment before go-live. A test report from the vendor describes its own scope, so compare it with the systems you will actually operate.

How the fixed scope and post-go-live support should be written

A written scope should move from data discovery through build, migration and handover to a defined support arrangement, so each stage produces a checkable output before the next one starts. Buyers can then compare proposals on the same sequence and see who is responsible at each point.

Agree the event plan and data sources
The implementation team reviews the events, properties, pages and app screens the business needs, and lists every data source that will feed the platform, such as web, mobile and back-end events. The buyer confirms which events are in scope and which are excluded. The step closes with a signed event plan and a source inventory, so later changes go through a defined change request rather than appearing as surprises.
Decide hosting, sizing and edition
The buyer and the implementation team record where the platform will run, how many events and replays are expected, and how long data will be kept. They also confirm which edition is needed and whether any proprietary features require a licence, since PostHog's README says premium features in its ee directory need a PostHog license on a self-hosted instance. The output is a written architecture decision with a sizing note that names the assumptions behind it.
Deploy and integrate the platform
The implementation team installs the chosen platform in the buyer's cloud account, data center or air-gapped network, configures single sign-on if it is part of scope, and connects the agreed sources. Work is tested in a non-production environment first. The step closes when the agreed events arrive in the staging environment and a named buyer contact has signed off the test results.
Configure masking and privacy controls
The team sets capture-time masking rules, input redaction, excluded pages and retention periods to match the privacy requirements the buyer has documented. Each rule is tested with sample sessions that contain realistic test data, not production data. The output is a masking test record and a retention configuration that the buyer's privacy or compliance lead approves in writing.
Migrate historical data where agreed
If historical data is in scope, the team defines the source, date range and import method before any data moves. Vendor tools have limits that must be written into the scope: PostHog's managed migrations cover at most one year per direct import job, do not deduplicate events, and offer no selective deletion once imported. The step closes with a reconciliation report showing record counts and any gaps the buyer has accepted.
Hand over documentation and run acceptance
The team delivers runbooks, architecture notes, configuration records and access lists, then runs the acceptance tests listed in the scope. Training sessions for the buyer's analysts and engineers are included if the scope says so. Acceptance is complete when the buyer signs the deliverables list, and any open items move into a named backlog with owners.
Define post-go-live support as a separate agreement
Support after go-live is written as its own agreement covering response expectations, upgrades, security patching and continuous testing if these are wanted. Ongoing support, upgrades and continuous testing are available as retainers, so they are priced apart from the fixed build. Buyers should also note that PostHog does not provide customer support for self-hosted instances, so any vendor support for a self-hosted deployment must come from a contract that names who responds.

How to score the responses

This table lists the seven areas a buyer should score in vendor and partner responses, with the weight to set, what a full score requires and what a partial score looks like. Set the weights before any response arrives, then record the reasoning behind every score so the decision can be defended later.

Area	Weight to set	Full score requires	Partial score looks like
Platform and edition fit	Set by your must-have features and expected event volume	Named platform and edition that covers session replay, funnels and the masking features you need, with the feature list confirmed in writing	Feature list stated in marketing terms only, or key features sit behind a paid edition not included in the quote
Licence obligations	Set by how many teams and environments you will run	Licence type for each component, the paid or enterprise directories identified, and a written view on what you may run without a separate licence	Licence named but proprietary components or license keys left unexplained
Migration of existing data	Set by how much historical data must move	Import method, time range per job, deduplication approach and any limits on deleting imported events stated in the response	Migration offered as a general capability with no stated limits or source systems
Hosting model	Set by your data residency and network rules	Deployment target, sizing tied to your traffic, and where session data is stored at every stage	Hosting described only as self-hosted, with no sizing, storage location or backup approach
Security evidence	Set by your regulatory obligations and assessor requirements	Hardening baseline, capture-time masking tests, access control design and sample evidence you can keep for an assessor	Assurances offered without documents, or evidence limited to the vendor's own product claims
Support terms after go-live	Set by your uptime needs and internal staff capacity	Named support hours, response routes, upgrade handling and who fixes what in writing, including for the self-hosted stack	Vendor community support only, or support described without scope or response terms
Scope definition	Set by how fixed you need the budget and timeline to be	Fixed scope with deliverables, exclusions, acceptance criteria and change control agreed in writing before work starts	Scope described as time and materials or as an open-ended retainer with no deliverable list

Answers that should worry you

Vendor and partner answers to an RFP reveal more than the feature list does. The red flags below cluster around three things: who supports the self-hosted stack, what the licence actually covers, and whether the scope and evidence are written down. Each card names the answer to challenge and the follow-up question to ask next.

Upstream support claimed without evidence

A bidder says the self-hosted edition is "supported by the vendor" with no written terms. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for product, infrastructure or other questions on self-hosted instances. Ask for the upstream support terms in writing, who answers the pager at 2 a.m., and which part of the stack the implementation partner carries under its own contract.

Licence boundaries ignored

Ask which directories and features the proposal relies on. PostHog's repository is MIT except the ee/ directory, which needs a PostHog license for premium features on a self-hosted instance. OpenReplay's ee/ directory is under a separate commercial licence. A bidder who cannot name these boundaries, or who quotes a free self-hosted build with enterprise features like SSO and audit logs, has not priced the licence cost. Ask for a licence inventory of every component in the design.

Full history migration with no stated limits

A promise to "move all historical data" should trigger questions. PostHog's managed migrations import from Mixpanel or Amplitude through API credentials, and each direct import job covers at most one year of data. Events are not deduplicated, and there is no way to selectively delete event data once imported. Ask for the source systems, the date range per job, the deduplication method, the test import plan and the rollback plan.

No written masking test plan for replay

If a bidder describes session replay masking as "configured at go-live" + "" without a test plan, the recordings may leak card numbers, balances or patient data. OpenReplay offers capture-time masking by CSS selector, input redaction and a private mode, but these controls must be verified after each front-end release. Ask for a written masking test plan that lists the selectors tested, the pages covered, the test accounts used and who signs off on results.

Open-ended scope without deliverables

A proposal that lists tasks like "ongoing optimization" or "support as needed" with no deliverables or acceptance criteria cannot be compared or enforced. Most credible engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for a numbered deliverables list, acceptance tests for each item, the change control process for new events or dashboards, and what the retainer covers after go-live.

Audit reports or certifications promised

A provider that says it will deliver a SOC 2 report, an ISO certificate or a HITRUST attestation for the analytics stack should be challenged. Independent auditors and certification bodies issue those documents, not implementation partners. A credible provider prepares systems, controls and evidence for an assessment. Ask who will issue the report, what evidence the provider will hand over, and which control owners on your side must sign off.

What buyers ask before hiring outside help for product analytics

How much does it cost to self-host product analytics with an outside partner?

Cost depends on the written scope, and DeployOpen does not publish a price list, so a quote follows from the agreed scope. Expect two kinds of spend: a one-time implementation fee covering planning, deployment, event instrumentation, masking configuration and migration, and recurring spend for hosting, storage, support and upgrades. The main drivers are event volume, the number of sources (web, mobile, backend), masking complexity, the scope of any historical migration and the support level you choose. Ask each bidder to split the quote into one-time and recurring lines, and to state which hosting costs are billed by your cloud provider and which by them. Figures should come only from a written quote.

How long does a self-hosted product analytics rollout take?

The duration is set in the written scope, and DeployOpen does not estimate timelines before that scope exists. The schedule usually depends on how many products and platforms need instrumentation, whether masking rules must be agreed with legal or security teams, whether historical data must be imported, and how quickly your team can review and approve each stage. Ask for a phased plan with named milestones, the client inputs each phase needs, and the acceptance tests that close each phase. A bidder who cannot tie dates to inputs and reviews is giving you a guess.

What does our team need to provide to an implementation partner?

The partner will need access and decisions from your side. Typical inputs include a tracking plan listing the events and properties you care about, a target cloud account or data center where the platform will run, network and DNS arrangements, identity provider details for single sign-on, and a named owner who can approve masking rules and retention periods. Security and privacy reviewers should be involved early, because capture-time masking decisions affect what is stored. Confirm in the statement of work which inputs are your responsibility and what happens if they arrive late.

Can our team deploy and run PostHog or OpenReplay without a partner?

Many engineering teams can deploy a small test instance themselves, and the vendors document that path. PostHog's self-host documentation describes a free Docker Compose (hobby) deployment, and OpenReplay's README says a single VM with 2 vCPUs, 8 GB of RAM and 50 GB of storage is enough to start self-hosting. The gap usually appears in production: upgrades, backups, masking tests after front-end releases, access control, incident response and documentation for reviewers. PostHog's self-host documentation states that self-hosted deployments are officially unsupported and that PostHog does not offer customer support for infrastructure questions on self-hosted instances. Decide which of these operating tasks your team will own before you decide whether to hire help.

Which parts of a self-hosted analytics project are one-time and which recur?

One-time work includes architecture, installation, SDK instrumentation, masking configuration, initial dashboards, historical migration and handover documentation. Recurring work includes infrastructure hosting, storage growth, platform upgrades, security patching, backup testing, retention enforcement, masking regression checks after releases and any ongoing support retainer. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which are priced separately from the fixed-scope build. Ask bidders to label each line as one-time or recurring and to state how renewal pricing is set, so the three-year cost is visible before signature.

How does event volume change the cost and the design?

Event volume affects storage, compute, database sizing and the point at which self-hosting stops being the simpler option. PostHog's README says open-source deployments should scale to approximately 100k events per month and recommends migrating to PostHog Cloud above that. PostHog's pricing page describes a free tier of the first 1 million analytics events per month on its cloud product, which is a useful comparison point when you model total cost. Umami Cloud's pricing page lists Hobby at up to 100K events, Pro at 1 million events and Business at 10 million events, with overage charges per extra event. Ask partners to model your expected volume at launch and at 12 months, and to show the storage assumptions behind it.

What should be in a written quote for a fixed-scope analytics engagement?

A usable quote lists the deliverables, the environments in scope, the number of platforms and SDKs, the masking and retention rules to be configured, the migration scope, the acceptance criteria and the exclusions. It should also name what is not included, such as data sources you add later, custom integrations or ongoing testing. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for the change-request process, the payment milestones and the support terms after go-live, so you can compare bids on the same terms rather than on headline totals.

Does an implementation partner guarantee that our analytics stack will pass a security review?

No partner can guarantee an audit result, and DeployOpen does not issue audit reports, attestations or certifications. What a partner can do is prepare systems, controls and evidence for a review: configuration records, access control settings, masking test results, retention settings, backup logs and documentation of data flows. Your auditor or assessor decides whether that evidence meets your obligations. Ask bidders which evidence they will hand over at go-live and which artifacts they will update during routine operations.

What to expect from DeployOpen in an evaluation

DeployOpen is a Chainscore Labs company. It plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and it supports them after go-live under a separate retainer if you want one. For product analytics and session replay, that work covers the analytics platform itself, its database and storage tiers, the capture settings in your front-end code, access roles and the operational runbooks your team inherits. DeployOpen also runs security testing of the applications and APIs that send events, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, so ask any vendor, including DeployOpen, to separate what it delivers from what your assessor must conclude.

Expect the commercial step to follow the scope rather than precede it. DeployOpen does not publish a price list. Most engagements are fixed-scope, and the scope, deliverables and timelines are agreed in writing before work starts, so a quote is produced from that written scope. Ask for the scope document to name the platform and edition, the hosting target, the events and replay volumes it is sized for, the migration sources in scope, the masking rules to be tested, and the support period after go-live. Confirm with DeployOpen which of these items are included in the fixed scope and which would be a separate change request. If an item you need is not in the written scope, it is not included, whatever was discussed in meetings.

How DeployOpen scopes, delivers and supports product analytics engagements

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For product analytics and session replay, that means the answers to these RFP questions become a written, fixed scope before any build work starts.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
The written scope names the platform and edition, hosting location, data sources and migration boundaries under review.
Quotes follow from that written scope, so each RFP answer should map to a line item the buyer can compare.

How we build

Deployment runs in your own infrastructure, so event and replay data stays under your control from the first install.
Capture-time masking, retention settings and access roles are configured and tested against the agreed privacy requirements.
Integrations with your identity provider, data sources and existing tools are built and validated against the written scope.

How we hand over

Handover includes configuration, deployment, backup and operating documentation for your own platform and operations teams.
Security evidence, such as configuration records and test results, is packaged for your internal reviews and compliance assessments.
We prepare controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after go-live.
Ask the partner to state in writing which upgrades, patches and incident response hours the retainer covers.
Security testing of the analytics stack, including the tracking SDK and replay masking, can be scoped alongside the platform work.

Product analytics RFP questions