Blog › ICP guides
Growth engineer on retainer: A/B testing infrastructure, referral program engineering, feature flag systems, and attribution pipeline development on monthly retainer
August 7, 2026 · ~21 min read
A 120-person B2C subscription SaaS company has a growth team that runs A/B tests using a third-party experimentation platform configured by a product manager who read the documentation two years ago. The VP of Growth has three problems: the experiments complete in 10 to 14 weeks because the sample size calculations were done at the platform’s default significance threshold (0.05) without power analysis, which means the company has been under-powered on most experiments and the majority of “negative” results may be false negatives; the referral program launched six months ago has a 40 percent higher fraud rate than industry benchmarks because the anti-fraud rules were not designed before launch; and the Meta Ads dashboard shows 3,200 conversions per month while the internal analytics database shows 1,800 paid signups in the same period, a discrepancy that has made it impossible to optimize ad spend with confidence. The company engages a fractional growth engineer on monthly retainer to rebuild the experimentation infrastructure, redesign the referral anti-fraud system, and implement server-side Conversions API attribution to close the reporting gap.
In month one of the retainer: a diagnostic audit of the existing experimentation setup that identifies three structural problems — the experiment assignment uses client-side JavaScript that fires after the page renders (creating a flicker that biases assignments toward slower connections), the sample size calculation uses a 5 percent MDE without verifying that a 5 percent improvement in the conversion rate metric would be business-meaningful (the product team discovers that the actual minimum meaningful improvement is 15 percent, which dramatically reduces the required sample size and explains why the tests have been running for 10 weeks without reaching significance), and the exposure logging includes re-visits to the assignment page that double-count the same user. The VP of Growth sees the diagnostic report. The 20 hours of event log analysis, code review, and statistical recalculation behind the three identified structural problems are not visible in the three-bullet-point summary.
Growth engineers and experimentation engineers on monthly retainer — independent growth infrastructure consultants, fractional growth engineering leads, and boutique growth engineering firms — perform their highest-value work in the experiment design, infrastructure debugging, anti-fraud rule design, attribution pipeline diagnostics, and funnel analytics engineering that precedes and validates every visible growth metric: the power analysis behind the sample size decision, the SRM debugging behind the valid experiment result, the fraud detection logic behind the clean referral conversion rate, and the CAPI implementation behind the reliable ad attribution report. This guide covers A/B testing and experimentation platform engineering, referral program engineering, feature flag infrastructure, server-side attribution pipeline development, and growth funnel analytics — and how to structure a growth engineering retainer that makes the hours behind each growth infrastructure function visible.
A/B testing and experimentation platform engineering
A/B testing infrastructure is the foundation of a data-driven growth function. The infrastructure must produce statistically valid results — if the experiment assignment is biased, if the exposure logging double-counts users, or if the analysis applies the wrong statistical test for the metric type, the experiment results are misleading and the product decisions made from them are based on noise. Building reliable experimentation infrastructure requires statistical engineering expertise alongside software engineering skills.
Experiment platform selection and architecture
The growth engineer evaluates experimentation platforms on three dimensions: Assignment consistency (whether the platform guarantees that the same user always receives the same variant assignment across sessions, devices, and page loads — a platform that uses a random number generator seeded with the current timestamp will assign the same user to different variants on different page loads, invalidating any experiment result); Exposure logging precision (whether the platform logs experiment exposure at the point when the user actually experiences the variant — not at page load, not at assignment, but at the moment the variant is rendered — and whether the logging correctly deduplicates re-visits by the same user within the same experiment); and Statistical analysis capability (whether the platform supports the statistical methods required for the organization’s experiment portfolio — frequentist significance testing with t-tests or z-tests for proportion metrics, Bayesian posterior probability for organizations that want to make decisions before reaching sample size, and CUPED variance reduction for noisy conversion metrics).
Commercial platforms include: Statsig (developer-focused experimentation platform with strong feature flags integration, CUPED variance reduction, and sequential testing; Warehouse Native mode stores raw experiment data in the organization’s Snowflake or BigQuery for custom analysis; pricing per event); Optimizely Feature Experimentation (enterprise platform with robust multi-page funnel experiments, mutual exclusion groups for running parallel experiments on overlapping audiences without interaction effects, and compliance-grade audit logging; higher pricing); and GrowthBook (open-source experimentation platform available self-hosted or as SaaS; connects directly to the analytics warehouse for metric queries rather than collecting events independently; strong for organizations that want to own their experiment data without a platform vendor dependency). The growth engineer also evaluates whether the organization’s scale and experiment volume justify building an internal experimentation platform — the approach used at Booking.com (Experimentation Platform built on their internal data warehouse), Airbnb (Experimentation Reporting Framework, ERF), and LinkedIn (XLNT) — versus the total cost of ownership of a commercial platform at the organization’s experiment velocity.
Statistical design: power analysis, MDE, and CUPED
The most common experimentation infrastructure failure is not a software bug — it is running experiments that were never designed to detect the improvements that matter. Statistical design requires: Minimum Detectable Effect (MDE) calibration (the smallest improvement in the primary metric that would be worth shipping the treatment variant if detected — calibrated to the business context, not defaulted to 5 percent; for a checkout conversion rate metric at 8 percent baseline, a 1 percentage point improvement (12.5 percent relative lift) may represent $2M in incremental annual revenue and is clearly worth detecting; a 0.1 percentage point improvement may not justify the engineering and design investment regardless of statistical significance); Sample size calculation (using the MDE, baseline conversion rate, desired statistical power (1-β, typically 0.80 or 0.90), and significance level (α, typically 0.05 or 0.01) to calculate the minimum number of experiment participants required per variant before the experiment can be analyzed without excessive false negative rates; the growth engineer uses the formula n = (z_α/2 + z_β)² × (p&sub1;(1-p&sub1;) + p&sub2;(1-p&sub2;)) / (p&sub1; - p&sub2;)² for proportion metrics or the equivalent for continuous metrics, with the expected traffic rate and variant split to translate sample size into an expected experiment duration); and CUPED variance reduction (Controlled-experiment Using Pre-Experiment Data, introduced by Deng et al. at Microsoft in 2013: using the participant’s pre-experiment value of the outcome metric as a covariate in the analysis to reduce the variance of the treatment effect estimator, allowing the same statistical power at a smaller sample size or the same sample size with higher statistical power; the growth engineer implements CUPED by computing the pre-experiment covariate for each experiment participant, fitting an OLS regression of the covariate on the post-experiment metric, computing the covariate-adjusted metric Y_CUPED = Y - θ × (X - E[X]) where θ is the OLS coefficient, and using the adjusted metric in the significance test).
Sequential testing and sample ratio mismatch detection
Sequential testing addresses the peeking problem: the inflation of false positive rates when experimenters check experiment results before the pre-determined sample size is reached and stop early if the result looks positive. Fixed-horizon tests (standard t-tests and z-tests) are only valid at the pre-determined sample size; checking the p-value at intermediate points and stopping early when p < 0.05 inflates the false positive rate to 30 to 50 percent at typical peeking frequencies. Sequential testing using the Sequential Probability Ratio Test (SPRT, developed by Abraham Wald in 1945 and adapted for internet experimentation by Wald’s generalization) computes a likelihood ratio statistic that can be evaluated at any point during the experiment with a controlled false positive rate, enabling valid early stopping when treatment is clearly superior or clearly inferior without sample size inflation. The growth engineer implements sequential testing by computing the SPRT statistic at each analysis interval, comparing against the upper stopping boundary (reject null, ship treatment) and lower stopping boundary (fail to reject null, do not ship treatment), and continuing the experiment if the statistic falls between the boundaries.
Sample Ratio Mismatch (SRM) detection is the diagnostic check that verifies the experiment assignment is working correctly. An SRM occurs when the observed proportion of participants in each variant differs significantly from the expected proportion (e.g., a 50/50 split experiment that assigns 52.3 percent to Control and 47.7 percent to Treatment has an SRM). An SRM indicates a bug in the assignment or exposure logging logic that biases the experiment results — the results of an experiment with an SRM cannot be trusted regardless of statistical significance. The growth engineer implements an automated SRM check that runs a chi-squared goodness-of-fit test against the expected assignment ratios on each experiment daily and alerts the experiment owner when a statistically significant SRM is detected (p < 0.01). Common SRM root causes include: client-side assignment logic that fires before the page renders, creating an assignment rate bias against slow connections; bot traffic included in the experiment that is not included in the analysis metrics; and A/A tests that reveal pre-existing differences between the assignment groups (indicating a broken randomization function).
Referral program engineering
Referral programs are the growth channel with the highest LTV-to-CAC ratio when they work correctly — and the most damaging to unit economics when fraud is not controlled. A referral program that pays $50 per referred signup and has a 40 percent fraud rate is paying $83 per legitimate referred signup while generating fraudulent account creation that inflates the company’s reported user metrics. The growth engineer builds the referral program infrastructure that maximizes legitimate referral conversion while minimizing fraud-driven reward payout.
Referral link generation and tracking
Referral link infrastructure requires: Unique referral code generation (generating a unique referral code for each referring user, stored in the application database alongside the referring user ID, creation timestamp, and usage count; codes should be short enough for human readability (6 to 8 alphanumeric characters) but sufficiently random to prevent guessing (50+ bits of entropy using a cryptographically random source, not a sequential counter); Click-to-conversion attribution tracking (persisting the referral code from the landing page click to the signup conversion across redirects, page refreshes, and browser sessions using a first-party cookie with a 30-day expiry, capturing the referral code in the signup form submission alongside the UTM parameters, and storing the referral attribution alongside the user account record at account creation); Referral conversion event instrumentation (emitting a referral conversion event when a referred user completes the qualifying action — completing email verification, making a first purchase, or completing a 7-day active usage streak — that triggers the reward fulfillment process for the referring user); and Reward fulfillment automation (integrating the referral conversion event with the reward fulfillment system — account credit, coupon code generation, gift card delivery via API, or webhook to the finance system for cash payout — with appropriate delays for fraud review before reward issuance).
Anti-fraud detection system design
Referral program fraud takes three primary forms: Self-referral (a user referring themselves using a separate email address to collect both the referrer reward and the referred-user discount); Bulk account creation (automated creation of large numbers of fake referred user accounts, typically using temporary email services, VoIP phone numbers, and rotating proxies, to collect referrer rewards at scale); and Reward farming (creating new accounts specifically to receive the referred-user discount with no intent to become a genuine user, then churning after the minimum qualifying period). Anti-fraud countermeasures include:
Email domain analysis (flagging signups from known temporary email domains — Mailinator, Guerrilla Mail, 10 Minute Mail, and the 3,000+ domains in the disposable email domain blocklist — for manual review before reward issuance; 85 to 95 percent of bulk account creation fraud uses disposable email addresses); Device fingerprinting (collecting browser fingerprint signals — user agent, screen resolution, timezone, browser plugins, WebGL renderer hash, and canvas fingerprint — and flagging referred user accounts whose device fingerprint matches the referring user’s device fingerprint (self-referral detection) or matches an abnormally high number of other referred accounts (bulk creation detection)); Velocity limiting (limiting the number of rewarded referrals a single referring user can generate per time period — typically a maximum of 5 to 10 successful referrals per month for consumer SaaS, with manual review for accounts exceeding the limit before additional rewards are issued); and Behavioral pattern analysis (analyzing the post-signup behavior of referred users for patterns that distinguish genuine users from fraud accounts — genuine users explore the product across multiple sessions over multiple days; fraud accounts either never log in after account creation or log in exactly once to satisfy the minimum qualifying period requirement). Anti-fraud system design and implementation — building the rule engine, integrating the device fingerprinting library, configuring the velocity limits, and tuning the detection thresholds against historical fraud and legitimate referral data — typically requires 20 to 40 hours before the system is ready for production deployment.
Feature flag infrastructure
Feature flags (also called feature toggles or feature switches) are boolean or multi-variant configuration values that control whether a feature, code path, or experiment variant is active for a given user, session, or environment. A feature flag system is the foundation of continuous delivery — enabling code to be deployed to production before it is released to users, allowing progressive rollouts to subsets of users before full release, and providing a kill switch to disable a feature that is causing errors or performance degradation without a code rollback.
Feature flag platform design and implementation
The growth engineer designs the feature flag system that meets the organization’s operational and experimentation requirements: LaunchDarkly (commercial SaaS feature flag platform with SDKs for 30+ languages, targeting rules (user attribute, segment, percentage rollout, and geographic targeting), flag variation types (boolean, string, number, and JSON), audit log, and scheduled flag state changes; pricing per seat; widely used by enterprises for the reliability guarantees and support SLA); Flagsmith (open-source feature flag platform with self-hosted and SaaS options; supports remote config (feature flags with associated configuration values), identity-based flag overrides, and A/B testing integration; no per-seat pricing in the open-source self-hosted version); and Unleash (open-source feature toggle service with enterprise SaaS option; supports 9 activation strategy types including flexible rollout with user ID hashing for consistent assignment, gradual rollout, and custom strategy plugins; strong for teams that require self-hosted infrastructure for security or compliance reasons).
For organizations that prefer not to depend on a third-party feature flag service, the growth engineer designs a lightweight internal feature flag system: a database table storing flag name, targeting rules (JSON object defining user attribute conditions and rollout percentages), and variant values; a backend service that evaluates targeting rules against the current user’s attributes and returns the assigned variant; a client-side SDK that caches flag values locally with a configurable TTL to avoid per-request latency; and a simple admin UI for flag creation, targeting rule editing, and state changes.
Progressive rollout architecture and kill switch design
Progressive rollout architecture controls the sequence in which a new feature is enabled for increasing percentages of the user base: Internal testing (flag enabled for the engineering team and internal beta users by user ID targeting before any external exposure); Canary release (flag enabled for 1 to 5 percent of production users, typically selected by a hash of the user ID modulo 100 to ensure consistent assignment, with monitoring of error rate, latency, and core metric impact for 24 to 72 hours before proceeding); Gradual rollout (incrementing the rollout percentage in steps — 5 percent, 10 percent, 25 percent, 50 percent, 100 percent — with monitoring at each step and the ability to halt progression if a metric regression is detected); and Full release (flag enabled for 100 percent of users, at which point the feature is “fully released” but the flag remains in place as a kill switch until the feature code has been running stably for a defined period and the flag can be cleaned up from the codebase).
Flag hygiene and technical debt management is the process discipline that prevents feature flag proliferation from becoming an operational liability. Each flag should have a defined owner, a creation date, and a planned expiry date. Flags that remain in the codebase past their planned expiry date create conditional code paths that increase cognitive complexity, complicate testing (each flag multiplies the number of code paths that must be tested), and — in the worst case — interact unexpectedly with each other when multiple flags are simultaneously in non-default states. The growth engineer implements a flag lifecycle policy: automatic Jira or Linear ticket creation when a flag passes its expiry date, a flag removal checklist for safe cleanup, and a monthly flag audit that reviews all active flags and closes those that are no longer serving their intended purpose.
Attribution pipeline development
Marketing attribution is the assignment of credit for a conversion event (signup, purchase, or subscription) to the marketing channels and ad campaigns that influenced the user’s decision to convert. Accurate attribution is the foundation of performance marketing spend optimization — if a company cannot accurately determine which campaigns and channels produce paying customers, it cannot allocate its marketing budget to the channels with the best return on ad spend. The growth engineer builds the attribution infrastructure that provides accurate, channel-complete conversion data despite browser tracking prevention, ad blocker usage, and cross-device user journeys.
Server-side Conversions API implementation
Browser-based pixel tracking — the standard approach to passing conversion events to ad platforms — has been progressively degraded by browser tracking prevention (Safari ITP, Firefox Total Cookie Protection, Chrome’s planned third-party cookie removal), ad blocker usage (25 to 40 percent of desktop users on performance marketing audiences), and the iOS 14.5 App Tracking Transparency (ATT) framework (requiring explicit user opt-in for cross-app tracking on iOS, resulting in 70 to 80 percent opt-out rates for most consumer apps). Server-side Conversions API (CAPI) implementations pass conversion events directly from the organization’s server to the ad platform’s API, bypassing browser-based tracking limitations.
Meta Conversions API (CAPI) implementation: the growth engineer builds a server-side event handler that receives conversion events from the application (signup completed, first purchase, subscription started) and sends them to the Meta CAPI endpoint (POST https://graph.facebook.com/v17.0/{PIXEL_ID}/events) with: the event name, event time (Unix timestamp), event source URL, user data (hashed email SHA-256, hashed phone SHA-256, hashed first name SHA-256, hashed last name SHA-256, country, and zip code), custom data (value, currency, content_ids), and action source (“website”); and the event_id deduplication key (a unique identifier that the Meta platform uses to match the server-side CAPI event with the browser-side pixel event fired for the same conversion, preventing double-counting when both browser pixel and server CAPI are active). The deduplication key must be generated before the browser-side pixel fires and passed to both the browser pixel and the server CAPI event — a common implementation bug is generating a different event_id for the server CAPI event than was used in the browser pixel, causing all CAPI events to be counted as new conversions rather than deduplicated against the pixel events.
Google Ads Enhanced Conversions implementation: the growth engineer implements the hashed user data transmission to Google’s Enhanced Conversions API, which improves the matching rate for conversions where the Google click ID (gclid) cookie is not available due to browser tracking prevention — the hashed email or phone number matched against the user’s Google account provides an alternative identity signal for conversion matching without the gclid.
UTM parameter capture and cross-device identity resolution
UTM parameter capture is the foundational attribution data collection step: persisting the UTM source, medium, campaign, content, and term parameters from the user’s first landing page click through the entire conversion funnel. A common implementation failure is UTM parameter loss at internal redirects — when the landing page redirects to a subdomain or different URL path for the signup flow, the UTM parameters in the original URL are lost unless the redirect explicitly preserves them. The growth engineer implements UTM persistence using: a first-party cookie with a 30-day expiry that stores the UTM parameters captured at first landing page touch; a session storage fallback for browsers in strict privacy mode that block first-party cookies; and a URL parameter inheritance mechanism that appends UTM parameters to all internal navigation links from the landing page to the signup form.
Cross-device identity resolution addresses the attribution challenge created by multi-device user journeys: the user who clicks a Meta ad on mobile, browses the product on desktop, and converts from a remarketing ad on desktop. Without identity resolution, the conversion is attributed to the desktop channel only — the mobile ad’s contribution to the conversion is invisible. Cross-device identity resolution uses deterministic matching (linking device sessions with the same authenticated user ID, email address, or phone number when the user logs in on multiple devices) and probabilistic matching (linking device sessions with the same first-party cookie fingerprint, IP address range, and usage pattern) to construct a cross-device user graph that connects all sessions from a single user across their devices.
Multi-touch attribution modeling
Last-touch attribution — assigning 100 percent of conversion credit to the last channel the user touched before converting — systematically overstates the value of bottom-of-funnel channels (branded search, direct, and retargeting) and understates the value of top-of-funnel channels (display, video, and content marketing) that create awareness but do not directly produce the conversion click. Multi-touch attribution models distribute credit across all touchpoints in the conversion path. Common models include:
Linear attribution (equal credit to each touchpoint in the conversion path — simple to implement and explain, but treats all touchpoints as equally valuable regardless of their position or type); Time-decay attribution (exponentially increasing credit to touchpoints closer to the conversion — the touchpoint 1 day before conversion receives more credit than the touchpoint 10 days before, reflecting the assumption that recent touchpoints are more causally related to the conversion decision); and Data-driven attribution using Markov chain or Shapley value methods (the growth engineer builds a Markov chain model from the organization’s historical conversion path data — modeling each channel as a state in the Markov chain and using the removal effect methodology to compute the contribution of each channel by measuring how often conversion paths succeed with vs. without each channel; or computing Shapley values from cooperative game theory, which distribute the “coalition value” of combinations of channels across individual channels based on their marginal contribution across all possible channel orderings). Data-driven attribution model development — collecting multi-touch path data, building the Markov chain or Shapley value computation, validating the model against holdout campaign results, and building the attribution dashboard — typically requires 20 to 40 hours of data engineering and statistical modeling work.
Growth funnel analytics engineering
Growth funnel analytics is the measurement instrumentation and analytical framework that gives the growth team a quantitative picture of user acquisition, activation, retention, revenue, and referral — the AARRR framework coined by Dave McClure — with enough granularity to identify the specific funnel stages and user segments where improvement investments will generate the greatest impact on the primary growth metric.
Event tracking architecture and warehouse modeling
Event tracking architecture defines the schema and collection approach for the behavioral events that power growth analytics. The growth engineer designs: Event taxonomy (the canonical list of events that the growth analytics system tracks, with standardized naming conventions — user_signed_up, onboarding_step_completed, feature_activated, subscription_started, subscription_churned — and a standard properties object schema that each event carries; the taxonomy is documented in a tracking plan that product managers, engineers, and data analysts contribute to and maintain); Collection infrastructure (using Segment or RudderStack as the event collection router that receives events from the web, iOS, and Android SDKs and routes them to the analytics warehouse (Snowflake or BigQuery), the marketing automation platform (Braze or Customer.io), and the product analytics tool (Mixpanel, Amplitude, or PostHog) simultaneously from a single instrumentation point); and Warehouse model (the dbt models that transform the raw event stream into the user-level and session-level analytical tables consumed by the growth dashboards — the user activation funnel table that tracks each user’s progress through the activation milestone sequence, the retention cohort table that groups users by signup week and tracks their weekly and monthly active usage, and the feature adoption table that tracks activation rates for each product feature by user segment).
Cohort retention analysis and LTV modeling
Cohort retention analysis groups users by the week or month they first converted and tracks the percentage of each cohort that remains active in subsequent weeks or months. The growth engineer builds the retention cohort model in the analytics warehouse: for each user, a row per cohort period (week or month since first conversion), with a binary active flag indicating whether the user generated any qualifying activity in that period. The resulting cohort retention matrix — where each row is a signup cohort and each column is a period since signup — reveals the retention curve shape that determines long-run LTV.
LTV modeling using survival analysis applies the Kaplan-Meier estimator to estimate the probability that a user who is active at period T remains active at period T+1 — the survival function S(t) = P(T > t) where T is the time to churn event. The Kaplan-Meier estimator handles censored observations (users who have not yet churned when the analysis is run) correctly, unlike a simple average churn rate calculation that must exclude these users. The growth engineer extends the survival analysis to segment by acquisition channel, pricing tier, and user attribute to identify the segments with meaningfully different retention curves — a segment with a 20 percent higher 12-month survival probability than the average represents a customer acquisition targeting opportunity worth quantifying and acting on.
HourTab for growth engineering retainers
Growth engineering retainer work produces growth metric improvements — experiment velocity increases, referral fraud rate reductions, attribution accuracy improvements, and retention curve shifts — that are visible in the dashboard. The hours behind each improvement — the power analysis behind the correct experiment design, the SRM debugging behind the valid experiment result, the anti-fraud rule design behind the clean referral conversion rate, and the CAPI deduplication key implementation behind the accurate attribution report — are not visible unless the growth engineer logs them with enough specificity to connect the hours to the growth infrastructure function performed.
HourTab gives growth engineers a retainer dashboard that their product and growth leadership clients can bookmark without creating an account: the month’s committed hours, the hours consumed to date, and the work log entries that connect each hour block to the experiment, the infrastructure system, or the attribution pipeline being worked on. When the VP of Growth can see that 14 of the month’s 60 retainer hours went to SRM debugging on the checkout experiment and 22 went to CAPI implementation and deduplication testing, the retainer usage discussion is grounded in the actual distribution of growth engineering work rather than an abstract sense of whether the month’s investment in growth infrastructure was worth the fee.
The retainer model works for growth engineering because infrastructure debugging and experiment cadence support are ongoing rather than project-scoped — every experiment requires a design review, SRM check, and results analysis; every referral fraud spike requires investigation and rule adjustment; every ad platform API change requires CAPI integration updates. A monthly hour commitment provides the growth engineer’s sustained availability across the full experiment portfolio and infrastructure maintenance calendar.
Frequently asked questions
What does a growth engineer on retainer typically do?
A growth engineer or experimentation engineer on monthly retainer provides ongoing growth infrastructure development: A/B testing and experimentation platform engineering (experiment design, CUPED variance reduction, sequential testing, SRM detection); referral program engineering (referral link tracking, anti-fraud detection with device fingerprinting and velocity limiting); feature flag infrastructure (progressive rollout architecture, kill switch design, flag hygiene); and attribution pipeline development (server-side CAPI implementation for Meta and Google Ads, UTM persistence, cross-device identity resolution, and multi-touch attribution modeling).
What growth engineering work is most commonly underlogged?
The most systematically underlogged categories are experiment design and power analysis (4 to 8 hours of statistical design invisible in the experiment brief), SRM debugging (6 to 16 hours of event log investigation invisible in the corrected experiment result), referral anti-fraud system design (10 to 20 hours of rule design and testing invisible in the fraud rate reduction), and CAPI deduplication debugging (8 to 20 hours of event tracing invisible in the corrected attribution report). Detailed work log entries that capture the specific experiment, system, and diagnostic work behind each hour block make this invisible infrastructure investment visible.
What should a growth engineering retainer agreement include?
Retainer agreements should specify: scope of engineering work (full-stack implementation vs. advisory and code review); monthly hour commitment and activity types; IP ownership for infrastructure code; access requirements for analytics warehouse, ad platform accounts, and production infrastructure; and escalation protocol for experiment anomalies. Monthly retainer amounts for fractional growth engineering support typically range from $10,000 to $25,000 per month covering 50 to 100 hours of experimentation platform development, attribution infrastructure, and referral program engineering.
What are typical retainer rates for growth engineers?
Independent growth engineers with 3 to 6 years of experience typically bill $125 to $225 per hour. Senior growth engineers with 7 to 12 years of experience and expertise in advanced experimentation methods (CUPED, sequential testing, interference correction) typically bill $200 to $350 per hour. Growth engineers at boutique growth engineering consulting firms typically bill $175 to $300 per hour. Monthly retainer amounts range from $10,000 to $20,000 per month for part-time engagements, increasing to $18,000 to $35,000 per month for comprehensive retainers where the growth engineer is the primary technical resource scaling experiment velocity from 5 to 30 experiments per month.
How should growth engineer retainer hours be logged?
Work log entries should capture the growth function, the specific experiment or system, the technical task, and the output. Example: “Experimentation Infrastructure — Checkout Flow A/B Test SRM diagnosis. Task: diagnose and resolve sample ratio mismatch detected in day-2 check. Work: pulled exposure log and confirmed SRM (52.3/47.7 vs. 50/50, p=0.003) — 2 hr; traced async rendering race condition in promo component — 4 hr; moved exposure log to component render callback — 3 hr; shadow test validation confirming SRM resolved (p=0.87) — 2 hr; recalculated results excluding biased days — 3 hr. Total 14 hours. Output: SRM root cause doc; fixed implementation; corrected experiment analysis showing +4.2% conversion at p=0.03.”