A swipe file is a collection. An ad intelligence database is a system. The difference sounds subtle, but it changes everything about how useful the library actually is.
A collection grows. A system compounds. This guide covers how to build one that actually makes your creative work faster and better over time.
The difference between a swipe file and an intelligence database
A swipe file is saved ads with no structure. You have them. You might look at them before a brief. That's it.
An intelligence database has the ads plus the context that makes them useful: why they worked, who they were targeting, how long they ran, what pattern they represent. You can query it. You can find things in it. You can use it to answer specific questions, not just browse for vague inspiration.
The goal is to build something you'd actually reach for when writing a brief, not something you scroll through hoping to feel inspired.
What goes into an intelligence database
Four types of information, combined, make an ad entry actually useful:
- The ad itself: the creative, the copy, the format
- Context: brand, category, where you found it, approximate date
- Performance signals: how long it's been running, active or inactive
- Your analysis: hook type, emotion, offer framing, what makes it work
Most swipe files have only the first item. The other three are what turn a folder into a database.
Data fields to capture for each ad
You don't need to capture everything. You need to capture enough to find things later and understand them quickly when you do. Here's a minimal but useful field set:
- Brand: who ran the ad
- Category: product type or industry vertical
- Format: video, image, carousel, UGC, static
- Hook type: question, bold claim, problem statement, curiosity gap, social proof
- Offer: what the ad is selling or promoting
- Estimated run time: still active, ran for weeks, ran for months
- Audience signal: cold traffic, retargeting, age/gender skew if visible
- Notes: one or two sentences on why you saved this
The notes field is the most important one. It forces you to articulate why the ad is worth keeping. Ads you can't explain in one sentence probably don't belong in the database.
How to structure for retrieval
The point of a database is to find things fast. You're going to be in a brief and need "three examples of problem-aware hooks in the skincare category." You need to pull those in under a minute.
Structure around the questions you actually ask. If you brief by hook type, tag every entry by hook type. If you plan by funnel stage, tag by awareness level. If you frequently brief by format, tag by format. The tags should match how you think, not some universal taxonomy.
Keep tags consistent. "ugc" and "UGC" and "user-generated" are three different tags that all mean the same thing. Pick one form and use it every time.
Tagging taxonomy: by emotion, funnel stage, and category
A three-layer tagging system works for most teams:
Layer one is category. Product type or industry: skincare, supplements, apparel, software, food. Broad enough to group things, specific enough to be useful.
Layer two is funnel stage. Cold, warm, or retargeting. Cold ads need to introduce the problem. Warm ads can assume awareness. Retargeting ads can reference past behavior. These are fundamentally different briefs and you want to find examples of each quickly.
Layer three is emotion or angle. Aspiration, fear, curiosity, social proof, urgency, transformation. This is where creative differentiation lives. When a category gets saturated with fear-based ads, the tag system helps you see it and deliberately brief something different.
Team workflow: who adds, who reviews
On a team, the database falls apart fast if everyone adds things differently. A few rules prevent this:
- One person owns the tagging taxonomy. Others use it. Changes go through that person.
- Every entry needs the notes field filled out. No notes, no add. This is enforced by the owner.
- Weekly review: 15 minutes to check new adds, remove duplicates, and promote the best to a "brief-ready" collection.
The weekly review is what keeps the database useful instead of just growing. Without it, you get quantity without quality, and the database becomes as hard to use as the Drive folder it replaced.
Connecting research to briefs to production
The database is only the beginning of the workflow. What you're building toward is a clear path from competitive observation to production-ready brief.
The path looks like this: you spot an ad pattern worth testing, you save it to the database with notes on what the pattern is, the pattern gets tagged and surfaces during brief prep, the brief references specific database entries as examples, the creator gets clear direction and working references.
Every step depends on the previous one being done well. Bad saves produce bad briefs. Vague notes produce vague direction. The discipline at the research stage pays off at the production stage.
Using Spreshapp as the intelligence layer
Spreshapp handles the parts of this that are hardest to build manually: permanent creative storage, automatic metadata, competitor tracking, and search.
When you save an ad from the Meta Ad Library using the Chrome extension, the creative is preserved permanently in your library. It won't disappear when the advertiser pulls the ad. The metadata comes with it automatically.
You add tags and notes on top of the automatic metadata. Your analysis becomes part of the record. Six months later, when you search for "problem-aware hooks in supplements," you get a filtered result set with your notes visible, not a folder of unlabeled screenshots.
The competitor tracking feature adds the proactive layer. Instead of going back to the Meta Ad Library periodically to check what competitors are running, you follow their domains and get notified of new ads. Competitive intelligence stops being a manual chore. For a deeper look at how to find what's actually working before you save it, the guide to finding winning ads on Facebook covers the research process from the start.
When to build custom vs use existing tools
Build custom if your research is highly specialized. If you need fields that no tool provides, or if you need to integrate ad research with internal performance data you own, a custom Notion database or Airtable setup can be worthwhile.
Use existing tools for everything else. The overhead of building and maintaining custom infrastructure is real. Most ad teams have more to gain from actually doing research consistently than from building a perfect system.
A well-tagged library in Spreshapp beats a perfectly architected Notion database that nobody updates. Start with what removes the most friction from your current process.
For how to use your database to produce better creative direction, the agency creative research guide covers the brief-writing process in detail.