Operations · Tools

Last Updated: August 10, 2026

Paid Media Audit Tool

A Tierra audit is a written teardown of a prospect's AppLovin account, delivered as its own web page. This guide covers the whole thing: what goes in an audit, what has to happen before you can build one, and how to build, review, and edit it.

What a Tierra audit is

An audit is how Tierra shows a prospect we understand their account better than they do.

We pull the last 30 to 90 days of their AppLovin data, read their actual ads, compare what we find against what they told us their problem was, and write up what's wrong and what we'd do about it. It's evidence, not opinion. Every number on the page traces back to something in the account.

The finished audit is a web page, not a slide deck or a PDF. It lives at its own address behind an access code, so only people you give the code to can open it.

Audits sit at two points in Tierra's process:

New business. A prospect from the AppLovin webinar funnel or an outbound conversation. The audit is what turns "we should talk" into a signed client.
Existing clients. A fresh set of eyes on an account, usually when performance has stalled or a renewal is coming up.

Either way the audit is a sales document. It gets reviewed internally before anyone outside Tierra sees it, and the Growth Strategist owns the decision to send it.

Two things you'll hear called the same thing

The intake form is the questionnaire the prospect fills in. The audit is the page we build from their answers plus their account data. People say "the audit" for both, so if it's ambiguous, ask which one.

The order things happen in

This is the part that's easy to get wrong. You can't build an audit the moment a prospect says yes, because two things have to arrive first: their intake answers, and access to their AppLovin account.

Here's the real sequence.

You create an intake link in the dashboard. That also adds the prospect to the dashboard list, so creating the link is what makes them exist in the tool.
You send the prospect two things together: the intake link, and a request for access to their AppLovin account.
The prospect fills in the intake form. Their answers save automatically as they go and land against their name in the tool.
The prospect grants AppLovin account access. This is usually the slow part and it's the one most likely to stall.
Once access is through, you copy their Account ID and Reporting Key out of AppLovin and paste them into the dashboard.
Now you can build. The build needs all of the above, and it will stop and tell you if something's missing rather than guess.
You review the finished page, publish it for internal review, and the Growth Strategist decides when it goes to the prospect.

Steps 1 through 5 happen in the dashboard and in your inbox. Steps 6 and 7 happen in Claude Code.

Don't start a build early to save time

A build with no intake answers and no account access produces a page full of holes that takes longer to fix than it would have taken to wait. If you're blocked on access, chase the access.

First-time setup

You do this once on each computer you work from. About ten minutes.

The dashboard needs nothing set up. Go to audit.tierraagency.com, sign in with your Tierra Google account, and you're in. If you only ever create intake links and check status, you can stop reading this section.

Building and editing audits needs Claude Code, and that needs a few one-time steps.

Before you start, you need:

Claude Code open on a folder that lives on your own computer. "On your own computer" is what people mean by "local", as opposed to files that live online. Claude Code 101 walks you through this from nothing. Do it through Step 4 and come back here.
Write access to the audit project on GitHub. Being in Tierra's GitHub organisation lets you read every project, and that part is automatic. Saving a change is separate and has to be given to you by name. Confirm you have it before you start, because read-only access does everything right up to the final save and then refuses, which means finding out after the work is done. Ask your GS to check.
The Tierra Data connector switched on. In the Claude desktop app, click the + in the message box, choose Connectors, and turn on Tierra Data. Nothing to sign up for, it's already there through your Tierra account. This is how the tool reads AppLovin data without any account passwords sitting on your computer.

Using Nimbalyst or Conductor instead of the Claude app?

Connectors work differently in other apps, and in some versions they're switched off entirely, which means the audit tool can't read any data. If Claude tells you the Tierra Data connector is missing and you can't find a Connectors menu to turn it on, use the Claude desktop app for audit work. Ask your GS if you're stuck on this.

Now the two steps. Each one is something you paste into the Claude Code chat as a message, exactly as written. Send one, wait for it to finish, then send the next.

Download the project onto your computer.

Clone the GitHub repo Tierra-Agency/tierra-audit-tool into the folder I have open, then tell me where it landed.

Cloning just means downloading a copy you can edit. The shared copy online stays where it is. Claude puts it in a subfolder called tierra-audit-tool, and you should note down where that ended up, because you'll want to be able to point Claude straight at it later.
Run the project's setup, once.

In the tierra-audit-tool folder, run: npm run setup

This does three jobs. It installs the pieces the tool needs to run at all. It switches on a check that watches every change you save, so that if a change would alter the tool itself rather than an audit, it stops you before anything saves. And it sets up how your saved changes are credited — automatically, so they reach the live site and carry your name, with nothing for you to set by hand. Without this step nothing works and nothing protects you, and none of it is obvious from looking.

It downloads a browser component as part of this, which is a large file. Expect it to sit there for several minutes on a slow connection. That's normal. Don't stop it.

That's it. There is no separate step to set the name your changes save under — setup handles that for you, and it's explained in Whose name your changes save under further down this page.

Then check it took:

In the tierra-audit-tool folder, confirm the protective check is switched on, and that my saved changes will publish under Tierra's shared dev account with my own name credited.

You want the check reported as on, and saving set to the shared dev account (tierra-dev) with your own name recorded as the credit. If either comes back different, run the setup command again before doing anything else.

Setup is invisible when it's missing

Nothing looks wrong if you skip it. Without setup, two things break quietly: an accidental change to the tool goes through instead of being stopped, and your work reaches GitHub but never appears on the site because it saved under the wrong name. Both are problems you find out about days later, which is why the check above exists.

This is not the same project as tierra

Tierra has more than one project on GitHub, and one of them is just called tierra. That's a different team's work and it has nothing to do with audits. The audit tool is Tierra-Agency/tierra-audit-tool, and it's the only one you need for this.

This matters because Claude will answer confidently about whichever project it happens to be looking at. Someone asked whether their audit tool was up to date and got a detailed answer about entirely different clients, because Claude was reading the wrong folder. If anything Claude tells you doesn't match what you expect, name the folder explicitly and ask again.

Where the project sits on your computer is up to you

It doesn't have to be inside any particular folder. What matters is that you know where it is, and that Claude Code has that folder open when you work on it. If you're not sure, ask Claude "what folder are we working in, and is the audit tool in it?"

You should never need to open Git, a terminal, or Git Bash yourself

Installing Git puts a program on your computer, and Claude Code uses it in the background. You don't open it. If you find yourself typing into a black window, stop and go back to the Claude Code chat.

You shouldn't have to approve much

The audit tool arrives with permissions already sorted. Reading, searching, and editing audits happen without asking you anything. Saving your work and anything that would touch the tool itself still ask every time, and that's deliberate. If you're being asked to approve routine things constantly, your copy is out of date, so tell Claude to pull the latest.

Step 1 — Create the intake link and send it

Go to audit.tierraagency.com and sign in with your Tierra Google account.

Fill in the form at the top of the page:

Client / brand name. Type this first.
Slug. This fills itself in from the brand name, as a lowercase version with hyphens, like acme-skincare. It becomes part of the audit's web address. Leave it alone unless it looks wrong.
Days. How long the intake link stays valid. It defaults to 90 days, which is almost always fine.
Account ID, Reporting Key, Campaign Management API Key. Leave all three blank for now. You won't have them until account access comes through, and you can add them later.

Click Create link. The link is created and copied to your clipboard, and the prospect appears as a new row in the table below.

Creating the intake link is what puts the prospect in the dashboard. There's no separate "add a prospect" step, so if someone isn't showing up in the list, they haven't had a link created yet.

Now send the prospect two things in the same message:

The intake link.
A request for access to their AppLovin account, so we can pull their data.

Sending both together matters. If you send only the form, you'll wait on access afterwards and the audit slips by a week.

Step 2 — Add the account details when access comes through

Once the prospect has granted access, open their AppLovin account and copy out:

The Account ID. A long number.
The Reporting Key. This is what lets us read their performance data.
The Campaign Management API Key, if it's easy to get. Optional, and the audit runs fine without it.

Back in the dashboard, find the prospect's row, and under AppLovin IDs click Add (it says Edit if something's already saved). Paste the details in and save.

You can check what's on file at any time. The keys are hidden by default, with Reveal and Copy buttons next to each one.

Enter keys only in the dashboard — never in Claude, Slack, or email

The Account ID, Reporting Key, and Campaign Management API Key give read access to the prospect's ad account. Enter them ONLY here in the dashboard. Never paste one into Claude, Slack, email, or a doc — the dashboard is the one place they belong. The build never needs you to hand it a key; it reads the account through the Tierra Data connector on its own.

Step 3 — Build the audit

The build runs in Claude Code, not in the dashboard. Work through First-time setup above before your first one.

Open a Claude Code window that is rooted in the tierra-audit-tool folder itself — in the desktop app, use Open Folder (or Select folder) and choose tierra-audit-tool; in Nimbalyst, the agent's workspace path must BE that folder. Do not paste audit prompts into a Claude window that already has some other folder open. If you're not sure, first ask Claude "what folder are we working in?" and confirm it answers tierra-audit-tool before you paste anything else.

Confirm the folder before you start

A teammate once pasted audit prompts into an unrelated window that happened to be open, and every audit ran from the wrong place — commits went to the wrong project and files landed in the wrong folder. The one check that prevents it: confirm the open folder is tierra-audit-tool before you do anything else.

Once you're in the right folder, tell Claude to get current first:

Check the repo and make sure the audit tool is up to date.

The build also updates its own copy at the start of every run, so an out-of-date copy corrects itself at kickoff — confirming it yourself first is just a good habit.

Then paste the template below and fill in the parts in square brackets. Delete the optional lines you don't need.

Run an AppLovin audit using the applovin-audit skill.

PARAMETERS
Client: [brand name]
AppLovin account ID: [account id]
Reporting window: [last X days from 30-90]
Attribution: [d0 or d7 if different from intake, optional]
Landing page: [url if different from intake, optional]
Prepared for: [name + role, optional]
Presentation date: [date, optional]
Additional notes or context: [all links separated by commas, optional]

Anything filled in here overrides the intake form.

FIRST, before pulling anything, confirm you can actually run. If the account ID is missing,
the intake answers are not on file, the account has no reporting key saved, or the Tierra Data
connector is not working, stop and say "BLOCKED" plus exactly what is needed. Do not attempt a
pull you know will fail.

If preflight passes, do NOT stop, do NOT report the preflight result, and do NOT announce what
you are about to do. In that same run, pull the account data, fetch the intake, and build the
evidence, then deliver the CHECKPOINT below. You have exactly TWO legitimate stopping points
before publish: the BLOCKED message, or the CHECKPOINT message. If you are about to end a turn
on anything else — a progress note, a plan, or a "now pulling the data" line — you are NOT done.
Keep working.

CHECKPOINT — report all eight of these in one message, then wait. Keep it terse; one line each
is fine, and say "nothing to report" for anything clean. Do not write any part of the audit
until I reply.

1. What you are reporting on: the client name the account ID resolved to, the exact dates, the
   attribution window, and whether that came from the form or from me.
2. Whether the account clears the data floor, or whether this is a test-plan audit.
3. Every intake answer you corrected, and why.
4. Competitors: which were links, which were names, what each name resolved to, and how you
   confirmed it.
5. The performance target you will judge everything against.
6. What is missing or could not be captured, and what you will do instead.
7. Anything in the data that contradicts what the client said their problem was.
8. Your open questions.

Then wait for my answers.

Anything you type into the PARAMETERS block wins over what the prospect put in the intake form. So if their form says one thing and you know better, put the better answer in the template.

The build has exactly two places it is allowed to stop before it publishes. Either it says BLOCKED and tells you what's missing (a wrong or missing account ID, no intake answers, no reporting key, or the connector down), or it reaches the CHECKPOINT — eight things it reports in one message, then waits. Read the checkpoint properly and answer it, because that's the cheapest moment to catch a wrong account, a wrong date range, or a competitor matched to the wrong company. Once you reply, it runs all the way to a published draft on its own, without stopping to check in.

Is it stuck, or just working?

Audits take a while and most of the run is quiet — that's normal, not stuck. What's not normal is a run sitting silent for an hour or more with no activity, or one that stops before the checkpoint. If that happens, reply with a single word: continue. The build saves its progress to disk as it goes, so "continue" picks up where it actually got to instead of starting over. If "continue" does nothing twice, send your Growth Strategist a screenshot. And run audits on Opus or Sonnet, not Fable — Fable burns more usage without being any faster for this.

The build marks the audit In Progress in the dashboard by itself when it starts, so there's nothing to click.

Step 4 — Review and publish

When the build finishes, read the whole page. You're checking that it reads like Tierra wrote it and that the numbers match what you know about the account.

The review and the numbers, before you ever see the page

Before you read it, the build runs two written review passes and a visual check of every screenshot — all on Tierra's servers, with nothing to set up and no key on your computer. And when a client's goal is measured on new customers only, the audit now reports AppLovin's native new-customer numbers (new-customer cost-per-purchase, cost-per-acquisition, and return on ad spend) at the D0 and D7 windows. There's no new-customer figure at the D28 window — AppLovin doesn't provide one — so if that's the client's headline metric, the audit says so plainly rather than substitute a blended number.

Then tell Claude to publish it. That puts the audit on the internal site behind its access code, ready for the team to review. Claude handles the publish itself.

To share it internally you need the access code. In the dashboard, find the prospect's row, look under Access Code, and click Generate if there isn't one yet, or Reveal to see the existing one. Open opens the audit page itself.

Publishing is internal review, not sending it to the client

Publishing puts the audit on the gated internal site so the team can look at it. Sending a prospect their audit is a separate step and the Growth Strategist owns it. Never hand an audit to someone outside Tierra without that sign-off.

When the audit is confirmed ready to go out, set its status to Completed using the dropdown in the dashboard. Completed means a person has confirmed it's client-ready, so it only ever gets set deliberately.

Audit status mostly looks after itself

Pending means nobody has started. It moves to In Progress on its own the moment a build starts, so there's nothing to remember there. Completed is the one that's yours to set.

Editing an audit later

Editing an existing audit is the most common job, and it's safe.

Audits live in the clients folder inside tierra-audit-tool, one page each, like clients/acme-skincare/audit.html.

Tell Claude to "pull the latest" so you're not editing an out-of-date copy.
Describe the fix plainly, name the audit, and say what should change. Being specific saves a round trip.
Claude shows you the change before applying it. This is called a diff, which just means the difference between the old version and the new one. Read it.
If it's right, tell Claude to commit and push. That saves your change back to the shared copy and the live audit updates a minute or two later.

A real example, close to how it's actually asked:

For the Acme Skincare audit, change the closing CTA from "Get in touch" to "Book a call". Make no other changes, then commit and push.

Saying "make no other changes" is worth the extra words. Without it, Claude sometimes tidies things you didn't ask about.

Getting asked to approve every small thing?

You shouldn't be. Reading and editing audits are already approved for you. Being asked constantly means your copy of the project is out of date, so tell Claude to pull the latest and try again. Don't go looking for a way to switch approvals off wholesale, because the ones that remain are the ones worth keeping.

What you can change, and what you can't

The tierra-audit-tool folder holds two different things, and the line between them matters.

The clients folder holds the audits themselves, one page per client. All of it is yours. Start a new audit, edit an existing one, correct a number, rewrite a section, swap an image. No permission needed.

Everything outside the clients folder is the machinery: the scripts that build an audit, the master template every new audit starts from, the sign-in and access-code system, and the instructions the review steps follow. One edit there changes every audit at once, including ones already sent, so only Brennan changes those.

You don't need to memorise which is which. Two separate checks watch for it.

The one on your computer stops the change before it saves and tells you what it caught. This is the one you turned on in step 2 of First-time setup, and it does nothing if that step was skipped.
The one on GitHub runs after your change has already saved and gone up. It can't refuse the change, so the live site will already have rebuilt from it. What it does is flag your change and email you and Brennan.

If either fires, check whether you meant to touch those files. If you didn't, ask Claude to undo everything outside the clients folder and save again. If the tool genuinely needs the change, tell your GS what you were trying to do. Don't try to get around either check.

Whose name your changes save under

Changes to this project save under Tierra's shared development account, with your own name added as a credit line on each one. This is automatic. The setup step (npm run setup) is what sets it up on every computer you work from: it records who you are, points your saved changes at the shared account, and adds your name to each one for you. You never set any names by hand, and you shouldn't try to.

The reason is narrow, and the failure it prevents is silent.

The live audit site only rebuilds when a change arrives under an account it recognises. A change saved under someone's personal account reaches GitHub, looks completely normal there, and the site never updates. Nothing tells you. You'd only find out by opening the audit and noticing your fix isn't on it.

This isn't theoretical. It happened here in July 2026: a teammate's fix went up under his own name, GitHub showed it as saved, and the audit page never changed. It took re-saving it under the shared account to get the site to pick it up.

Saving under the shared account keeps the site rebuilding. The credit line keeps the record of who actually did the work, so nothing is lost by doing it this way.

If a change of yours reached GitHub but never appeared on the site, this is the first thing to check. The Troubleshooting section below has the fix.

The one rule that matters most

Never have two people in the same audit at once

Each audit is a single file. If two people build or edit the same audit at the same time, one person's work gets overwritten, and that has actually happened here. Before you start, check nobody else is in it. Different audits are separate files and don't clash, so two people on two different audits is fine.

Troubleshooting

Find your symptom below. If none of these match, send your GS a screenshot of exactly where you are and what you were trying to do. Don't guess past an error, and don't let Claude talk you into working around a check.

Claude tells me about audits or clients I don't recognise, or says my copy is out of date when I know it isn't.

It's looking at a different project. Tierra has more than one on GitHub, and one of them is just called tierra, which is a different team's work and has nothing to do with audits. The audit tool is Tierra-Agency/tierra-audit-tool. Name the folder explicitly and ask again, for example "look in the tierra-audit-tool folder specifically and tell me if it's up to date." Don't act on an answer that doesn't match what you expect.

I've never seen the check that's meant to stop me changing the audit tool.

It probably isn't switched on. It gets turned on by the project's setup step, which is step 2 of First-time setup on this page, and until that's been run nothing on your own computer stops an accidental change to the tool. Run that step, then the check at the end of that section. If you set the project up before August 2026, run it again anyway, because older copies didn't switch the check on.

I'm not sure whether the audit tool setup steps actually worked.

Ask Claude directly: "In the tierra-audit-tool folder, confirm the protective check is switched on, and that my saved changes will publish under the shared dev account with my name credited." You want the check on, saving set to the shared dev account (tierra-dev), and your own name recorded as the credit. Anything else means setup didn't take, so run npm run setup again from the First-time setup section on this page.

Claude says the Tierra Data connector is missing.

Turn it on: in the Claude desktop app, click the + in the message box, choose Connectors, and enable Tierra Data. Then start again. If you're in Nimbalyst or Conductor rather than the Claude app, connectors work differently there and in some versions they're switched off entirely, so switch to the Claude desktop app for audit work.

The build stops immediately and says it can't run.

That's deliberate, and the message tells you what's missing. It's one of four things: no Account ID saved, the prospect's intake answers aren't on file, no Reporting Key saved for the account, or the Tierra Data connector isn't working. The first three are fixed in the dashboard, and the order they need to arrive in is covered above under "The order things happen in". The build refuses rather than producing a half-empty audit.

An audit build stops partway or looks incomplete.

Ask Claude "what went wrong and can you pick up where you left off?" first. If it can't recover, send your GS a screenshot of the last thing that happened.

A prospect isn't showing in the dashboard list.

Nobody has created their intake link yet. Creating the link is what adds them to the dashboard, so there's no separate step for adding a prospect. See Step 1 above.

I can't open an audit page, it's asking for a code.

Every audit sits behind an access code. Find the audit's row in the dashboard, look under Access Code, and click Reveal to see it, or Generate if there isn't one yet.

My change didn't show up on the live site.

Two things to check. Did you tell Claude to "commit and push"? Saving locally isn't enough on its own. And have you waited a minute or two? Live sites rebuild shortly after a push, not instantly. If it's been several minutes, see the next entry.

My audit change saved to GitHub but the live site never updated.

The live audit site only rebuilds when a change arrives under Tierra's shared development account. If yours went up under your personal name instead, the update is quietly refused and nothing tells you. This has happened for real, so if the page hasn't changed, this is the reason. It almost always means npm run setup hasn't been run on this computer — setup is what points your saved changes at the shared account and credits them to you, automatically. Run npm run setup now so it stops happening, then tell Claude: "re-save this under the shared Tierra dev account with me credited on the change," and check the site again in a minute or two.

Claude says my change was not saved because it edits the audit tool.

That's working as intended. Everything in the client folders is yours to change. Everything else builds every audit and runs the live site, so only Brennan changes it. Check whether you meant to touch those files. If you didn't, tell Claude "undo everything outside the client folders and save again." If the tool genuinely needs the change, tell your GS what you were doing. Don't try to get around the check.

I got an email from GitHub saying the audit tool was changed, or there's a red mark on my change.

That's the second of the two checks, the one that runs on GitHub rather than on your computer. It fires after your change has already saved and gone up, so the live audit site has already rebuilt from it. Don't try to unpick it yourself. Tell your GS straight away what you were changing, so it can be put back if it broke something. Then do step 2 of First-time setup on this page, because getting this email usually means the check on your own computer wasn't on.

Claude Code 101 — the general setup you do before the build steps here
GitHub Basics — the account, the Git install, and what cloning and pushing mean
AppLovin Playbook — the AppLovin background an audit assumes you have