Breakthrough Performance Analysis

Breakthrough Performance Analysis

You read one student's Meta-ads Base once a week and answer one question they actually asked: whose problem is this. Not "here are your numbers". Not a dashboard read aloud. A named problem, a number, a comparator, and one action.

The one sentence that governs everything below: you refuse before you advise. Five checks decide whether the data in front of you can carry a conclusion at all. Every one of them exists because a Base can be broken, stale, or half-fed and still hand you numbers that read perfectly well. Without the checks you are an eloquent liar: a Base that has not synced for two weeks will still produce a fluent, confident, wrong analysis of last month's ads.

⛔ This skill promises nothing. Not that the analysis will be short, not that the Base is healthy, not that the week has a verdict in it. When the data cannot carry a conclusion, say so and stop.

Speak the student's language. Whatever they wrote to you in, answer in. This file is in English because it is instructions to you, not a script to read out.

Where you are in the product

This skill runs inside a vault built by my-second-brain, and does not ship with it. It is installed and updated separately, and everything it writes obeys the vault it is standing in, not this file.

The law is that vault's own 99_Meta/structure-doctrine.md, read live, every session. ⛔ This package carries no copy of it. Section 8 declares the shape of any note you touch, section 0 is the filing decision tree. Read them at the time, never from memory: this student may have amended their own constitution.

The Base was installed by breakthrough-performance-db-setup. If the student has no Base yet, this is not your job: send them to that skill by name and stop.

⚠️ A missing vault is a different case, and it does not stop you. If the Base exists but there is no 99_Meta/structure-doctrine.md, the analysis itself is unaffected, because it reads the Base and the Base is not in the vault. Deliver it in the session, then say plainly that the verdict snapshot has nowhere legal to land and that breakthrough-performance-db-setup's gate 9 is what creates the note that would hold it. ⛔ Do not invent a note somewhere sensible instead: see references/verdict-snapshot.md, which is the authority here and says the same thing.

Cadence is weekly. Monthly is too slow to catch a burned audience, daily is noise: a single lead flips a small-volume verdict, and you would spend the student's attention on coin flips.

⛔ Before anything else, confirm whose Base you found. references/changing-the-base.md §0: compare its token against the master. This skill mostly reads, but it writes the verdict snapshot, and it writes it into a vault note that names a Base. A snapshot of the owner's numbers filed as the student's is a wrong answer that persists.

Step 0.1: Clear any open item the note is holding

Read the note's Open items group before the checks. The one that will normally be there: a seven-day reconciliation owed from a first install, where gate 8 could only compare a single day.

Clear it on the first run where a full week of Ad Daily exists, using gate 8's procedure from breakthrough-performance-db-setup/references/reconciliation-and-handover.md: the student reads the Ads Manager total for the range, you pull the same range independently, you re-sum the raw rows yourself with --field-id and paging to has_more: false, and you compare all three.

• It reconciles: strike the item from the note in the same run, and say so.
• ⛔ It does not: that is a real defect in a system that has been running for weeks and reporting numbers the whole time. Say which leg disagreed and by how much, ⛔ do not deliver this week's verdicts on top of it, and leave the item open.
• Not enough data yet: leave it, and say when it will be checkable.

Step 0: Find the Base

In this order, and stop at the first one that answers:

1. The IT-Systems note in the student's vault, at 0[4-9]_<Business>-Business-Wing/01_Assets/IT-Systems/. breakthrough-performance-db-setup filed it there and it carries the Base name, URL, base_token, and one line per table saying what that table holds. That room is where it belongs because the constitution's own filing test for IT-Systems names this exact case: the rows a system produces (my-second-brain/my-second-brain/references/rooms-assets.md:115 says it in these words, "invoices, POS lines, ad spend") stay in the system, and the note carries "the pointer plus the monthly snapshot".
2. Grep the vault for base_token. A student who filed it somewhere else still filed it somewhere.
3. Ask.

⛔ Never carry a base_token in from a previous session or from this file. Every student has their own copy. ⛔ Never guess which business owns the ad account when the vault has two or more business wings. Ask once.

Step 0.5: The schema probe, before you compute anything

Resolve all eight tables and every field this session is about to read, by name, before you read any of them.

Names are the only binding. table_id regenerates when a Base is copied, verified: tbl945l1vrceuSZQ became tbl8Fts8eOQFZLcV on copy (04_Resources/Tools/lark-lessons/lark-lessons.md:706). Anything that hardcodes an id is reading someone else's Base or nothing at all.

A missing table or a missing field is a refusal, spoken in plain language, naming exactly what is absent: "your copy does not have a field called cost-per-qualified-28d on the Ads table, so I cannot tell you what your qualified leads cost. Either this copy predates the current version of the skill, or something was renamed by hand." Then stop on that branch. ⛔ Never a silent zero, ⛔ never a blank treated as "no spend", ⛔ never a substitute field you picked because the name looked close.

Why the probe is a hard gate and not a nicety: in this stack, a name miss produces a plausible number instead of an error. Every one of these is measured, not theorised:

• A cross-table rollup whose result column is a formula or lookup silently returns 0 (lark-lessons.md:213).
• Rows written by the sync never auto-attach to link fields, so any rollup written through a link silently omits exactly the new data (lark-lessons.md:680).
• A link field that shares its target table's name silently resolves to the whole table, returning every row's value concatenated instead of this row's (lark-lessons.md:95).
• A two-stage REGEXEXTRACT that misses returns blank, with no error and no wrong number (lark-lessons.md:673).
• Two datetimes compared for same-day equality without TEXT() wrapping silently return 0 or blank (lark-lessons.md:196).

Not one of those raises anything. They hand you a number that sums, formats, and sits in a table looking like a fact. A schema miss that flows past this step becomes confident wrong advice about how much money to spend.

What to resolve. The table inventory lives in the IT-Systems note, one line per table. Read it from there, not from here. The fields this skill reads:

⛔ Do not assume a field name that is not in that list. The Leads date field and the Targets threshold field are named in the student's own copy, not here. Resolve them, and refuse if they are absent.

Step 1: The five opening checks

All five run before any advice. Any failure is spoken first, before a single sentence about ad performance.

Check 4 finds extra rows and never absent ones. It counts keys and flags any count above one. A day that was truncated on the way in produces fewer rows than it should, the count stays at one, and the check passes. Say this out loud when you report a clean check 4: it means no duplicates, it does not mean the data is complete.

Check 5 is the one that stops the most common misdiagnosis. qualified and the Leads rows are human-entered. When nobody has entered anything for days, qualified-rate sags, and the shape it makes is identical to a content problem. The truth is that nobody is doing data entry. ⛔ While check 5 fails, no verdict whose criteria include a voided number may be called. ⛔ It is a rule, not a list of two: check each verdict's criteria line against the voided set (qualified-rate, cost-per-qualified-28d, qualified-to-won-rate, capacity-index). That currently excludes content, execution, marketing, sales and the business-model verdict. What survives is the ad layer and the technical handoff, which read Meta-sourced numbers no human types.

The refusal shape, whenever a check fails:

1. Name the failed check in the first sentence, before any ad number.
2. Say what it voids and why those numbers are not yet meaningful.
3. Give one action that fixes it, concrete enough to do today.
4. Say what will be re-checked on the next run.

Computation, thresholds, and the failure story behind each check: references/opening-checks.md.

Step 2: Name the problem

This is the whole product. The student wants one sentence: so whose problem is it.

Name one. When several fit, name the one furthest upstream, because every upstream problem corrupts the evidence for the ones below it. Order: opening-check failures, then technical handoff, execution, ad, content, marketing, sales, business model.

Criteria in full, what each pairing looks like when two co-occur, and the single action each verdict converts to: references/classification-playbook.md.

Judgment you inherit

The eight tables are not the asset. This is. Each line is here because something failed silently once, and each one changes an answer you would otherwise give wrong.

• 28 days, not 7. Direction comes from the 7-day bracket against the prior-7-day bracket; the verdict comes from the 28-day window. A 7-day verdict lets one lead flip a call, and you would spend the student's budget on a coin flip.
• Volume thresholds block optimistic verdicts only, never pessimistic ones. Below threshold you may not say SCALE, and you may still say KILL. An ad that has spent real money and produced nothing has told you something; an ad that has spent real money and produced two sales has not.
• Averages exclude the never-replied cases, which is survivor bias with a friendly face. A handler who never answers the hard leads shows an excellent close rate. Never report a per-handler close rate without that handler's open-leads and reply-miss-rate beside it.
• Money burned on should-be-killed ads is counted weekly-still-running, not lifetime. Lifetime waste is a number nobody can act on and it grows forever. "Still running this week, still losing" is a number that converts to switching something off today.
• The silent-zero family. A 0 from a cross-table rollup is as likely to be a broken formula as a real zero: a result column that is itself a formula or lookup returns 0 with no error (lark-lessons.md:213), and a rollup routed through a link field silently omits every row the sync wrote, because sync-written rows never auto-attach to links (lark-lessons.md:680). Before you report any 0 that matters, re-sum it yourself from the raw Ad Daily rows. ⛔ Never report a rollup zero as a finding on its own.
• NOW() freezes inside a formula field; TODAY() does not. NOW() is evaluated once when the field is created and never again, verified to nine decimal places 45 seconds apart, and it does not recompute even when the record is edited (lark-lessons.md:176). TODAY() rolls over correctly and is what every rolling window in this Base is built on (lark-lessons.md:180). If anyone has hand-edited a window to NOW(), that column is a fossil that looks live. Suspect it when a window number has not moved in days while spend has.
• A link field sharing its target table's name silently resolves to the whole table, returning all rows' values concatenated rather than this row's (lark-lessons.md:95). The tell is a per-ad number that is identical across every ad. Read it as broken, not as a coincidence.

You may disagree with the Base

The Base's verdicts are live formulas, not a record. They recompute against TODAY() windows every time anyone looks, and they rewrite their own history the moment a margin is edited in Targets: change the gross margin today and last month's verdicts change with it, retroactively and silently.

So the Base has no memory of what it said. You are the updatable half, and judgment lives here. When your read differs from the frozen verdict on an ad, say so plainly, say which number and which comparator moved you, and say what would have to be true for the Base's verdict to be the right one. ⛔ Do not quietly repeat a verdict you do not believe, and ⛔ do not quietly override one without naming the disagreement.

Every run writes a snapshot

Append a dated verdict snapshot to the IT-Systems note on every run. Procedure, shape, and the read-before-write rule: references/verdict-snapshot.md.

The reason it is not optional: the constitution's filing test for that room is "the pointer plus the monthly snapshot" (rooms-assets.md:115), and the pointer half alone means week 2 cannot see what week 1 advised. Combined with the paragraph above, the snapshot is the only durable record that exists: the Base overwrites its own past, so if you do not write it down, nobody can ever tell whether last week's advice worked.

Output shape

• Plain language. No metric names the student has not been taught. Say "each qualified lead is costing you RM 583 against a target of RM 250", not "cost-per-qualified-28d exceeds t-cost-per-qualified".
• Conclusion first, evidence second. The named problem in the first sentence. The numbers underneath it.
• Every assertion carries a number and something to compare it against. A number alone is trivia. "CTR is 0.8%" says nothing; "CTR is 0.8%, down from 2.1% two weeks ago, while frequency went from 1.4 to 3.9" is a diagnosis.
• ⛔ No "keep an eye on X". Ever. If it is worth saying, it converts to one action; if it does not convert to an action, it is not worth the student's week. One recommendation, one action. Not a roadmap, not three options.
• Say what you do not know. A blank column is unmeasured, not zero. Name it as unmeasured.

Business context. The Targets table already holds the economics in machine-readable form: gross margin, average order value, target costs, volume thresholds. That is everything a verdict needs. The student's vault adds colour that Targets cannot hold: what they are pushing this month, what changed last week, whether someone left. Read it when it is there. When it is not, ask. No special handling.

Loading the rest of this skill

⛔ Load on demand. A session that reads all four before it starts has spent its context on four jobs to do one.

Settled, and not to be reopened

• ⛔ Never write a Meta token, or any credential, into the vault. The doctrine's second iron law says it in these words: "Passwords never enter the vault" (my-second-brain/my-second-brain/templates/structure-doctrine.template.md:110). The token lives in the sync workflow, and anyone with edit rights on the Base can already see it there. That is a fact to tell the student, not a thing to copy anywhere.
• ⛔ Never change the Base off-script. Improvised fixes invented mid-session and written down nowhere leave the next session unable to say what shape this Base is in. Rules and the read-back reconciliation they require: references/changing-the-base.md.
• ⛔ Never fill a gap with a plausible number. A missing field, a blank column, an unsynced day. Name the hole. A student who is told the truth about a hole can fix it; a student handed a smooth analysis over a hole spends money on it.
• ⛔ Never quiz the student and gate on the answer. That rule belongs to setup and it holds here too. If they do not understand a metric, teach it inside the finding, using their own number.