How the work runs

The read, in order

  1. Define the decision

    The account does not start the review. A decision does, and "improve performance" is not one. The question, its owner, the date window, the platform boundary and the known constraint are written down before the account is opened.

  2. Verify what the account counts

    The chosen action is traced from the page or the app into the system used for bidding and reporting, and into the business record where one exists. The result is a traced path and a verdict on which counts can carry a decision.

  3. Inspect where the money went

    Allocation and structure are read in the order that matters for this decision. The allocation record stays separate from any claim about what the allocation produced.

  4. Inspect the destination and the business path

    The read goes only as far as the decision requires and records what happens after the click and where a lead stops being visible.

  5. Separate findings, hypotheses and unknowns

    A finding has a source behind it. A hypothesis explains a pattern and still needs a test. An unknown cannot be settled from the record available. Every observation is labeled as one of the three.

  6. Write the finding

    Output: the finding in its twelve fields, listed below.

  7. Rank corrections by dependency and decision value

    Measurement defects usually come first, because later budget and bidding decisions inherit the signal. The ranked correction brief says why item one comes before item two and what can run in parallel.

  8. Choose the smallest useful next scope

    Diagnosis can end at the written finding, and that is a complete engagement. The record names the next scope or states that there is not one.

  9. Keep the account owner in control

    Read-only wherever possible, and every live change inside a named boundary with an approval record. Output: the approval rule in writing, and the prior state recorded for each change.

  10. Verify the correction

    Output: the verification read, the change date, and the pre-change and post-change windows kept apart.

The twelve fields every written finding carries

  • The decision being examined.
  • The account and platform boundary.
  • The evidence source.
  • The measurement basis.
  • The date window.
  • The observed condition.
  • The business consequence the evidence supports.
  • The limitation.
  • The recommendation.
  • The approval owner.
  • The verification step.
  • The next decision.

The fields are the point. A finding with a recommendation and no basis, no window and no limitation is an opinion with a number attached to it. When the record cannot support a consequence, the limitation field says so, and the recommendation drops to a test or a request for evidence rather than a change.

See the paid diagnostic

Questions people ask

How long does a read take?

The triage and the diagnostic each state their own window on their own page. A read that needs longer than its window says so before it starts, not after.

What do you not look at?

Anything the named decision does not require. I do not audit every tag on a site or every campaign in an account for its own sake, because that produces a long document and no decision.

Who approves a change?

You do, or one person you name. For a direct engagement that is the account owner or whoever they appoint.

What record comes back with a change?

Nothing in a live account moves until the approver accepts an itemized list in writing. The prior state of each setting is recorded before the change, so any of it can be put back, and the change log is delivered with the work so your team can answer a question about it without asking me first.