AI agents for growth data analysis
Know which revenue questions your data can actually answer
Built the growth engine that took cnvrg.io to its acquisition by Intel.
I personally build growth data-analysis workflows that connect permitted advertising, product, CRM and commercial sources. The work can answer funnel, cohort, retention and revenue questions, expose data-quality gaps and prepare scenario or experiment readouts with their assumptions. I lead the measurement strategy, implement the agreed connections and deliver analysis that can be retraced.
Begin with a decision the report needs to support
The first question might be whether to investigate a paid channel, repair an activation step or change a lifecycle journey. We define that decision before choosing charts. I map the population, conversion stages, time window and available source authority so the same word does not quietly mean different things in different systems.
B2B pipeline, B2C acquisition and ecommerce orders need different models. A qualified opportunity is not a paying account, an order is not necessarily collected revenue and a product event is not proof of customer value. The agent works with definitions we can maintain and check.
| Question | Required evidence | Useful output |
|---|---|---|
| Did paid leads progress into opportunities? | Observed source, deduplicated inquiries, accepted CRM stages and date rules | A traceable funnel plus unmatched records |
| Where do new users fail to activate? | Accepted activation definition and instrumented product events | A cohort analysis with event-coverage limits |
| How much revenue followed these orders? | Order, cancellation/refund and payment evidence on an agreed basis | A reconciled report labelled by the actual revenue definition |
| Why do the dashboards disagree? | Source definitions, transformations, timestamps and identity keys | A discrepancy list with the next repair owner |
The analysis can include extraction, cleaning, segmentation, cohort and retention comparisons, or a forecast built from explicit assumptions. I agree the question, eligible population, identity joins and source windows before implementation. An agent-assisted interpretation is not a substitute for a valid denominator or a causal experiment.
For an ongoing shared KPI surface, I also build dashboards and recurring reporting from the accepted metric model. A maintained board and an ad-hoc investigation have different outputs and ownership.
What the agent does, and what remains explicit
I implement source extraction or approved exports, mappings, reconciliation checks and an answer format with links back to the underlying evidence. An agent can investigate a discrepancy, prepare a narrative or propose the next query. Metric calculation, identity joins and population filters need an explicit, repeatable contract.
The result can be a scheduled operating review, an investigation queue or a checked answer to a recurring question. Full-funnel analytics covers the broader measurement implementation. Marketing attribution is relevant when the question concerns assigned credit across touchpoints rather than a reconciled funnel.
| Approach | Useful when | Important limit |
|---|---|---|
| Existing dashboard with corrected definitions | The data path exists and the main problem is consistency | A new agent may add little value |
| Rules and scheduled reconciliation | The same sources and checks recur | Novel questions still need investigation |
| Agent-assisted investigation | A discrepancy needs contextual explanation and follow-up queries | Every substantive conclusion still needs source support |
| Causal experiment | The decision needs incremental impact | Attributed revenue alone does not prove causation |
Worked example: the CRM says won, but billing is incomplete
Illustrative input and expected output only. WF-ANALYTICS-01 is a synthetic acceptance fixture; it is not a live data connection or completed analysis of a client.
Input: a permitted CRM export contains an opportunity marked won. The billing source is unavailable or its account relationship cannot be resolved. The reporting question asks for collected revenue by acquisition source. A confident revenue number would hide the missing evidence.
| Input state | Expected report output | Next step |
|---|---|---|
| CRM opportunity is won | Report the observed won state using its agreed definition | Retain the opportunity ID and stage timestamp |
| Billing feed is unavailable | Collected revenue remains unavailable | Assign the missing-source investigation |
| Billing record exists but account join is ambiguous | Put the record in an unmatched population | Resolve identity before attributing it |
| No source was captured for an account | Keep an explicit unknown-source category | Do not redistribute it across observed channels |
| Same event is present twice | Apply the accepted deduplication key | Show the retained identity and excluded replay |
| Period boundaries differ between sources | State the discrepancy rather than compare incompatible totals | Reconcile date basis and timezone |
Build a report the next person can reproduce
I personally design and implement the agreed measurement work, QA the joins and calculations, and deliver the operating review. When the input instrumentation is wrong, tracking diagnosis can be part of the repair. I can also manage the workflow after handoff when ongoing operation is included.
- A metric dictionary with populations, events, stage transitions, units, windows and known exclusions.
- Source access and transformations included in the project, with lineage to the output.
- Identity and duplicate rules, unmatched-record views and missing-source handling.
- Evaluation cases for incomplete periods, delayed events, failed extraction and incompatible definitions.
- A reporting output, operating instructions and named responsibility for changes and exceptions.
Work with Yaniv
Built the growth engine that took cnvrg.io to its acquisition by Intel.
Keep a checked reporting version and a clear operating owner
I connect the agreed advertising, product, CRM and billing sources through supported reads, approved exports or warehouse models. The integration records the account, extraction window, identity key and transformation version, so a later report can be compared on the same basis. A new warehouse or a specific vendor is selected only when the task needs it.
An agent can investigate discrepancies and prepare explanations. I implement and test the joins, calculations, source checks and report, and the designated business owners accept metric definitions and consequential budget decisions. Source-record mutations are a separate scope; an analytics question does not authorise changing customer or payment facts.
Before replacing a reporting model, retain the last accepted model and output. Check a fresh extraction against the agreed fixture and reconciliation criteria, then promote the accepted version. If refresh or checks fail, keep the failure visible and the last valid output labelled with its actual period; do not silently publish stale numbers as current.
| Operating point | Who owns it | Acceptance evidence |
|---|---|---|
| Definition and population | Business/metric owner with my measurement design | Events, units, windows and denominator accepted |
| Build and source reconciliation | I implement the agreed connections and models | Reproducible query plus source and exception records |
| Report release | Named reporting owner and agreed checks | Accepted model/output version and freshness label |
| Recovery and handoff | Named operator or my managed reporting scope | Last valid version, failed-refresh procedure and runbook |
Judge useful reporting by decisions and reconciliation
Compare the time required to answer the same recurring question before and after the pilot, including review and corrections. Check reproducibility, unresolved records and whether decision-makers can distinguish a missing source from a genuine zero. A faster report that conceals uncertainty is not an improvement.
The business case depends on report frequency, source maintenance, review effort and the cost of acting on a wrong answer. We measure these in your workflow. No fixed time saving, attribution accuracy percentage or revenue increase is assumed.
| Check | Pass condition | Failure condition |
|---|---|---|
| Population and denominator | Included and excluded records can be explained and reproduced | Changing the denominator silently changes the conclusion |
| Metric reconciliation | Output matches the accepted calculation and source basis | CRM won is presented as collected cash |
| Incomplete evidence | Missing sources and unknown joins are visible | Missing input appears as observed zero |
| Narrative support | Each substantive claim points to its evidence | An agent explanation adds unsupported causality |
| Operating recovery | A failed refresh is visible and the last valid state is labelled | A stale report appears current |
Scope the first question, then expand the system
We agree a useful decision, the sources that can support it and the form of the accepted answer. The first build can repair one recurring report or connect a broader acquisition-to-revenue path. Existing infrastructure, permissions, data quality and your team determine the scope.
Bring the question people argue about, two conflicting reports if available and the owners of the relevant data. I will define what can be answered now, what I will implement and what needs another source before it can be accepted.
Tracking and data-quality exception review
When a metric disagrees with the source, I trace missing or duplicate events, identity joins, consent/permission state, schema changes and freshness. The deliverable is a source-bound discrepancy, reproducible case and agreed repair/retest, with a named owner for the remaining gap. An unavailable report is not an observed zero.
If the repair includes returning eligible CRM or purchase outcomes to advertising, conversion feedback defines the event and transmission contract separately.
Questions before the build
Will you implement the measurement work or only write recommendations?
I personally lead the strategy and implement the agreed source connections, definitions, reporting logic and checks. Where your developers or data team must make a change, I define the dependency and verify the receiving output. We agree handoff or ongoing operation as part of the engagement.
Does this replace our BI platform or data warehouse?
It does not need to. The workflow can use an existing warehouse, reports or approved exports. I first check where the actual problem sits: instrumentation, identities, definitions, access or interpretation. New infrastructure is proposed when the accepted question needs it, with its cost and ownership made explicit.
Can the agent tell us which channel caused revenue?
It can help prepare an attribution analysis using an agreed method and available source evidence. Assigned credit is not the same as incremental causal impact. If the decision requires causation, we need an appropriate experiment or other defensible causal design rather than a stronger sentence around an attribution report.
What happens when CRM and billing do not match?
Keep the states separate and surface the discrepancy. A won opportunity may be reported as won; collected revenue needs payment evidence on the agreed basis. Unmatched identities stay in a visible exception population instead of being allocated to a channel by guesswork.
Do you support B2B, B2C and ecommerce reporting?
Yes. I build around the commercial model and the permitted sources. B2B inquiries, opportunities and contracts; B2C users, activation and purchases; and ecommerce orders, returns and payments each need their own definitions and checks.
How current will the report be?
Freshness depends on the source refreshes, processing and review needed. We define the reporting window, expected delay and stale-state behavior before operation. A failed refresh must not appear as current data, and a partial period must not quietly be compared with a complete one.
What do we receive at the end?
The agreed implementation, metric and source definitions, reporting output, reconciliation cases, exception ownership and operating documentation. I demonstrate how to reproduce an answer and handle a failed source. Additional reporting questions and ongoing management can be scoped after the initial work.
How do we recover from a broken refresh or a wrong reporting model?
I retain a last accepted model/output version and define the checks before replacing it. A failed refresh stays visible and the last valid report is labelled by its actual period. If a model must be reverted, restore the accepted calculation and rerun reconciliation; do not change source financial records to make a report agree. The operating handoff explains who can approve a release, investigate unmatched records and maintain the connections.
Personal strategy and execution
Define the first workflow we can build and check
Tell me which recurring decision or task needs to improve, which systems exist and who receives the output. We will define the build, checks and handoff or ongoing operation for your client/project scope.