Skip to content

Growth Intelligence System / Quattr

Turning expertise into
repeatable growth programs.

“Which pages should we work on next?” A useful answer needs customer context, a defensible method and a deliverable the team can act on.

Problem
Recurring growth questions across customers with different data and priorities.
My role
Designed the analytical skills and built the internal system around them.
Decision
Separate account configuration from reusable analytical methods.
Output
Structured recommendations, implementation records and client reports.
Supported result
A prioritization export covering 812 pages, with 100 shortlisted for review.

Archived output · 19 November 2025

A defined place to start

812pages in the export→100shortlisted pages
First three ranked rows · page identities anonymized
PageClicksImpressionsQueriesPriority score
Page 01822338,5945,80590.75
Page 0288101,9322,42425.09
Page 0310893,7641,77422.94

The decision to review: Page 01 surfaced with a priority-term signal. Review its demand and commercial relevance, then assign the next investigation. The score does not estimate incremental revenue.

Newly typeset, sanitized excerpt of the retained report; values preserved. Counts describe the export. The measurement window is not independently verified. Inspect the displayed values ↗

Start with the customer decision

A ranked list needs a reason to act

A page inventory could contain organic demand, business-event signals and paid investment pointing in different directions. I wanted the method to preserve that context and give the customer a concrete next investigation.

The associated workflow reconciled signals around a canonical page, applied configurable scoring and retained reasons for review. The output made priorities inspectable. The shortlist gives the customer a defined starting point for implementation planning and follow-up.

The design decision

Keep the method reusable. Make account meaning explicit.

I designed the analytical skills and built the Growth Intelligence System around them. A skill defined the question, required data and structured result. The registry and client ontologies held account-specific context, definitions and dataset availability.

That separation let a recurring question become a reusable method without treating every customer’s data and business priorities as interchangeable.

Ownership: this was my internal analytical and delivery system. Quattr’s commercial platform and its product capabilities were built by Quattr’s product and engineering teams. Customers and their teams owned changes in their own environments.

From analysis to delivery

Make the next step explicit

  1. Capture the decision: name the customer question, owner and intended action.
  2. Resolve the context: consult configured sources, definitions and availability.
  3. Apply the method: preserve assumptions, inputs and errors with the result.
  4. Shape the delivery: turn the finding into a report, work queue or review conversation.
  5. Improve the method: carry feedback and unresolved questions into the next iteration.

Supporting examples of analytical judgment

Question the measurement before the conclusion

Moneyball: the population changes the answer

The retained December 2025–February 2026 lifecycle analyses use different cohorts: an earlier 761-URL population and a refined 380-URL population with observed search activity. Crawl-log coverage and lifecycle windows matter when interpreting apparent performance. A held-out baseline returned negative R², so the evidence supports investigation and method development—not predictive superiority.

TimesFM: connect a forecast to the planning question

The forecasting skill work organizes inputs and outputs around business drivers and segments. The retained February 2026 goal-and-channel summary records two goals, four channels and a 28-day horizon: 224 output rows. Output-shape checks and explicit model/fallback labels help make execution inspectable. Those rows do not establish forecast accuracy.

These are separate applications. Moneyball’s changing cohorts are not a before/after outcome. The recovered Prophet workbook is not a TimesFM backtest.

Inspect the technical method and source context

Skills return data, explanation and errors

@dataclass
class SkillResult:
    success: bool
    data: Any = None
    explanation: Optional[str] = None
    errors: List[str] = field(default_factory=list)

Partial excerpt from the retained Python skill base class. The full implementation also carries execution metadata.

Account configuration declares availability

data_catalog:
  gsc:
    bulk_export:
      database: PROD
      status: available
      alias: searchdata_url_impression
      primary_table: GOOGLE_SEARCH_CONSOLE_BQ_<CLIENT>.SEARCHDATA_URL_IMPRESSION

Sanitized presentation excerpt from an archived client ontology; client identifier generalized. Not a runnable configuration.

Runbooks, data access and the internal MCP

Runbooks define how agents consult account context. DatasetGuard and ClientResolver provide dataset-resolution paths. Python analytical workflows use Snowflake data, while the internal MCP exposes a consistent tool interface. Retained implementation includes infrastructure verification paths; legacy and cached paths have documented limitations.

The archived material includes internal system design, generated recommendations and implementation records. The prioritization export is dated 19 November 2025; the observation period is not recorded in the displayed excerpt.

What this means for a B2B technology company

The work connects a product’s analytical capability to the customer’s next decision. It makes specialist reasoning easier to inspect and gives a team a structure for repeating and improving delivery.

For a company investing in SEO or AI search, the same discipline connects a growth question to sources, a method, an owner and a reviewable next action.

Inspect the output and the method.

For the system-design method: turn a recurring question into an analytical skill.