# Festival season 2027: the planning checklist for the data part

> Everything on this list has to exist before the announcement, because none of it can be added retroactively. Fifteen items, in the order they become impossible.

Source: https://hiipe.io/blog/festival-season-2027-data-checklist
Published: 2026-10-29

Site plans have a checklist. Supplier contracts have a checklist. Insurance, licensing, accreditation and stage schedules all have one. The audience data usually does not, and it is the only part of a festival that genuinely cannot be fixed in the week before the gates open.

**Key takeaways**

- Consent, source and attendance are written at a moment or not at all.
- Run this before the announcement. After the on-sale, half of it is already impossible.
- If you do one item, do the consent wording, stored with a timestamp per person.

## What this list is not

It is not the operations checklist. Nothing here concerns fencing, water, medical
cover or noise limits, and those matter more than any of this on the day.

It is the list of things that can only be captured while they are happening. A
supplier contract can be renegotiated. A consent record cannot be created in
March for a person who signed up in June without it.

## Before the announcement

This is the part that is genuinely urgent, because it has to exist before the
first person arrives.

| # | Item | Why it expires |
|---|---|---|
| 1 | Agree the consent wording, in each language you sell in | It must be the wording shown at the moment, and stored |
| 2 | Decide the source tags, one per surface | A tag added later is a guess, not a source |
| 3 | Set up the pre-announcement list | It only works before the line-up is known |
| 4 | Export last edition's audience, with source and consent | Before anyone cancels a subscription |
| 5 | Write down who the controller is, and who the processors are | [Article 30 of the GDPR](https://gdpr-info.eu/art-30-gdpr/) asks for this anyway |

Item three is the one with the highest return and the shortest window. A list of
people who asked to be told when the line-up lands is the single best predictor
of launch week, and it can only be built while the line-up is still unknown.

## During the on-sale

| # | Item | Note |
|---|---|---|
| 6 | Every purchase path leaves a contact with a source | Including the ones your partners run |
| 7 | The sold-out page has a waiting list | Not a dead end with a word on it |
| 8 | Partner and sponsor capture is agreed in writing | Who holds it, who can message, for how long |
| 9 | One reminder to the pre-announcement list, on the day | The whole point of building it |

Item eight is the one that causes arguments in February. Agree it while everyone
is friendly, in a paragraph, and store the wording shown to the person on both
sides.

## On site

| # | Item | Note |
|---|---|---|
| 10 | Attendance is recorded per person, not as a headcount | This is the field that makes next year's best segment |
| 11 | Any on-site capture writes its own source tag | The bar, the merch stand, the workshop tent |
| 12 | Staff know the one sentence to say when asking | Consent collected badly is worse than none |

Item ten is worth arguing for internally. A number in a report tells you the
edition worked. A record per person tells you who to invite next time, and the
gap between those two is a year of marketing budget.

## After the gates close

| # | Item | Timing |
|---|---|---|
| 13 | The recap send, within a week | Highest open rate you will get all year |
| 14 | Quarterly export, held outside every vendor account | Twenty minutes, and it survives anything |
| 15 | Two segments built and saved | Attended and did not return; attended two or more editions |

The reason to build the segments in the quiet week rather than next spring is
that you will remember what the data means now, and you will not in eight months.

## Where the mechanism helps

Most of this is discipline rather than software. The part software should do is
enrichment: every action landing on the profile at the moment it happens, so that
attendance, opens and purchases accumulate without anyone updating anything. That
is what HIIPE does with the fanbase, and it is why items ten and fifteen stop
being projects. [How it fits together](/solutions) covers the rest.


## Who owns each part, and why the list stalls without that

Most of these checklists die because they are written by marketing and depend on
production, ticketing and the people on the gate. Naming the owner in advance is
the difference between a list and a document.

| The part | Who has to do it | Why it stalls |
|---|---|---|
| Consent wording, in every language sold | Marketing, with a legal read | Waiting for perfect wording instead of shipping a clear one |
| Source tags per surface | Whoever configures the surfaces | Nobody feels ownership of a naming convention |
| Pre-announcement list | Marketing | Competes with the announcement itself for attention |
| Attendance recorded per person | Ticketing and the gate | Reads as an operations burden with no visible payoff |
| The quarterly export | One named person, calendared | Everyone assumes someone else has a copy |

The fourth row is the one that needs a sponsor rather than a request. Recording
attendance per person costs the gate team a small amount of friction on the
busiest night of the year, and the benefit lands eleven months later in a
different department. That trade has to be made by someone senior enough to make
it, or it does not get made.

## If you are already mid-cycle

The whole list assumes autumn. Most people read something like this in April, with
tickets already on sale, and conclude they have missed the window. Two thirds of
it is still available.

1. **Do the consent wording this week.** It applies from the next signup onward,
   and the next signup is today. Nothing here is retroactive, which is exactly why
   starting late costs you nothing forward.
2. **Add source tags to the surfaces still to come.** The ones already live keep
   their gap. Partial data is not a reason to skip the rest of the season.
3. **Do the export now, not in October.** The single highest-value item on the
   list, and it takes twenty minutes at any point in the cycle.
4. **Skip the pre-announcement list this year.** It only works before the line-up
   is known. Put it in the calendar for the autumn instead of doing a bad version
   now.
5. **Record attendance per person at the next event**, even if you cannot for the
   ones already gone. One clean edition is enough to build next year's best
   segment.

## When to review this page

Once a year, in the autumn before the season it applies to. The version you are
reading is dated 29 October 2026 and is written for the 2027 season. If you are
reading it later than that, the items have not changed but the dates have, and
the argument for doing it early is in [festival marketing happens in the eleven
months without a festival](/blog/festival-marketing-between-editions).

**Read next** : [When a festival is cancelled, where does the attendee list go?](/blog/when-a-festival-collapses) · [A guest list app fills the room. It does not build a contact list](/blog/a-guest-list-is-not-a-contact-list)
## Citable facts

- Article 30 of the GDPR requires a written record of processing activities, naming who the controller is and who the processors are. A festival that writes that down before the season opens has already completed most of its data checklist.
  Source: Regulation (EU) 2016/679, Article 30, records of processing activities
- Consent, capture source and attendance cannot be added to a contact record after the fact. If they were not written at the moment of capture, they do not exist.
  Source: Definitional, HIIPE
- A festival's data work has to be finished before the first gate opens. Once the season is running, the only thing still under control is what gets written down, not what was already missed.
  Source: HIIPE, September 2026

## FAQ

### When should this checklist be run?
Before the announcement, which for a summer festival means autumn or early winter. Everything on it becomes harder once tickets are on sale and impossible once the gates have closed, because the moments it depends on will have passed.

### What is the single most important item?
The consent wording, stored with a timestamp against each person. Everything else can be reconstructed with effort. Consent cannot, because it is a record of something that happened at a specific second.

### We already use a ticketing platform. Is that enough?
For selling, yes. For the list, check one thing: whether a full export gives you the buyer with a capture source and a marketing consent record attached. If it gives you names and emails only, the list is a mailing list and not an audience.

### How long does this take?
Most of it is decisions rather than work. The parts that are work, mainly agreeing the wording and setting the source tags, are a day. The reason it does not get done is not effort, it is that nobody owns it.

### Who should own this checklist inside a festival team?
One named person, and almost never the marketing lead alone. Half the items sit with production and ticketing, so the owner needs to be someone who can ask both for a small thing and get it. In practice it works best with whoever runs the ticketing relationship.

### What if we are already mid-cycle and none of this exists?
Do items one and two only, and do them for the next surface you publish rather than retroactively. Everything on this list is about what gets written at the moment of capture, so starting late costs you the past and none of the future.

### Do we need consent from people who bought a ticket?
For sending them information about the event they bought, generally no, that is part of the transaction. For telling them about next year, that is marketing and it needs its own basis, which in most cases means a separate, optional question asked at the time.

### How long should we keep attendee data?
Long enough to be useful and short enough to be defensible, which for a festival usually means the full cycle plus two or three editions. Write the period down, apply it, and say what it is. An undocumented retention period is the one that causes problems later.