A brief is due Thursday. You open the board where 400 competitor ads have been piling up since spring, scroll for 20 minutes, close it again, and write the concept you already had in your head on Monday.

The board cost you nothing. It also did nothing.

I have kept files like that for years: Drive folders, a swipe tool, once a shared Notion database with a colour-coded tag system I was proud of. Saving was never the part that broke.

Short answer: A competitor ad swipe file earns its keep when a written rule decides what goes in, not your eye. Sweep a fixed roster of advertisers on a schedule, save whatever clears the rule, and stamp each entry with the date you first saw it and the date you last confirmed it running.

The takeaways

The save rule matters more than the tag schema. An eye-picked file records what an ad platform chose to show a person who works in marketing, plus whatever you found handsome that week.
Runtime is a measurement you take twice. An ad saved on day 12 has proven nothing yet. The date you last saw it live is what turns the entry into a longevity read.
A roster of 8 to 12 advertisers beats an open feed. Direct competitors at your price, two substitutes, one out-of-category brand you keep for craft, swept on the same day each month.

Why does a swipe file stop answering questions?

Because it is a record of what reached you. Two filters ran before anything got saved: an ad platform decided which ads to serve someone who works in marketing, and then you kept the ones that looked good. Neither filter knows anything about the market you buy in.

The first skew is the one nobody names. Your feed over-serves advertisers who target marketing-interested audiences, which is why every media buyer's swipe file fills up with agency offers, course launches and software. If you sell orthopaedic insoles, that file portrays somebody else's market.

The second skew is craft. A screenshot shows production quality better than it shows anything else, so production quality is what you select on, and craft was never what your account was missing.

What decides which ads go in?

A roster and a written save condition, both fixed before you open the ad libraries. Pick 8 to 12 advertisers: the direct competitors whose price and buying trigger match yours, two substitutes your buyer weighs instead of you, one or two out-of-category brands you keep purely for craft. That list is the decision worth arguing about.

Then write the condition down. Mine is boring: from the roster, anything running 30 days or longer that I have not already got, plus anything new since the last sweep. No clause in it refers to how the ad looks.

The roster is the artifact you maintain, and the file is just its output. Adding a competitor is a real decision. Saving one ad should not feel like one. When the file goes stale, you fix the roster.

Why does every entry need two dates?

Because runtime is the only performance proxy a public ad library hands you, and it is a reading taken at one moment. An ad you saved on day 12 might have been switched off on day 14. It might still be running next spring. Both got filed as the same screenshot.

So stamp two dates: first-seen, and last-confirmed-running. Once a month, sweep the roster again and update the second date on every entry still live. That pass takes 20 minutes and it is the only maintenance the file needs.

What you get is a shortlist that sorts itself. Entries that keep collecting confirmations are the ads a competitor kept paying for through months of their own kill decisions, and those are the ones worth briefing from. A longevity tier tagged once at save time bakes in a number that went stale as you typed it.

Which fields earn a column?

The ones that answer a question you ask on brief day. Write those questions down before you design the schema. Mine are almost always about the offer, the objection the ad is handling, and who it is talking to, so those become the first three columns and everything else has to argue for its place.

Six fields cover it: the offer and its commercial terms, the objection the ad answers, the awareness stage it speaks to, the hook mechanism, the format and placement, and the two dates. Keep the permitted values as a closed list, or "founder", "Founder" and "owner on camera" become three attributes by March.

Skip anything the screenshot already holds. Colour, layout and typeface are visible in one glance and unqueryable in a filter. The reasoning underneath is what goes missing, which is the argument behind decoding each ad into a row rather than a screenshot.

What can a swipe file never tell you?

Whether any of it made money. The public ad libraries publish no spend, no CTR, no conversions and no targeting, so even a well-kept file tells you what a market ran and how long it survived somebody else's judgement. That is a hypothesis generator. It settles nothing.

At scale it gets slippery. 400 entries will support almost any claim someone walks in with: everyone is doing founder-on-camera now, filter for it, nine examples, and a quarter of briefs rests on a search that could not have come back empty.

Treat a surviving pattern as a candidate. Pull the three or four durable ads behind it, break the videos down properly, and put the resulting structure into a test in your own account.

Where this stops being manual

The monthly sweep is the part I have skipped on plenty of accounts, which is exactly how a swipe file rots. That maintenance is why the loop is built into Adscalr: the Meta, TikTok and Google ad libraries land in one normalized dataset refreshed daily (nothing here is real-time), anything still running past 30 days is flagged as a durable winner, and a vision model decodes each static into roughly 20 structured fields with design, copy and strategy scores.

The limits do not move. No spend, no targeting, the same public record you would be reading by hand. What changes is that the dates keep updating, and updating them is the part people abandon. That maintained cross-library record is what competitor intelligence is for.

How to build a competitor ad swipe file