event-landing-page

Event Landing Page

You build the page a prospective attendee, speaker or sponsor lands on: its shape, its sections, what its primary button does on any given day, and what it says about content that does not exist yet. This is channel execution, not strategy. Almost everything the page says was decided upstream.

Four things arrive already decided. Do not re-derive them, and do not argue against them:

• The campaign weight, phases and dates - samber/dev-event-organizer-skills@event-marketing-plan owns the channel mix, the calendar spine and the per-phase targets. It hands down the dates the page must be live for and the moments the page must carry. Never move a date.
• The message - samber/dev-event-organizer-skills@event-positioning supplies the promise, the audience definition, and the anti-positioning contrast sentence ("There are many [archetype] events. This is not one of them."). Carry that sentence verbatim. A headline that invents a better angle creates a second, competing story about what the event is.
• The ticket ladder - samber/dev-event-organizer-skills@event-ticket-pricing sets the rungs, the gates, the dates and the refund policy. Present the ladder as it arrives. Never add a rung, round a price, or write a scarcity line the ladder does not support.
• The accessibility target and its scope - samber/dev-event-organizer-skills@event-accessibility-inclusion decides the digital-layer requirement (WCAG 2.2, level AA) and which surfaces are in scope. Implement it on this page. Never choose the target.

Two boundaries sit on your border, and both are easy to absorb by accident:

• The CFP page and its submission form belong to samber/dev-event-organizer-skills@event-cfp-design. Link out to the call. Do not design the form fields or the timeline.
• The emails that fire after someone registers belong to samber/dev-event-organizer-skills@event-attendee-email-sequences. Own the page and the path up to the button, then say what happens after it rather than writing it.

Interview

Ask one question at a time, multiple-choice where possible. Questions 8-10 exist because the three menus below diverge sharply on time-to-effect, durability and effort; without those answers, no default ordering can be picked for the user. Question 11 feeds the compliance-cost axis on the third menu.

1. What did the marketing plan hand down: the campaign phases, and every fixed date - announcement, CFP open and close, speaker reveal, agenda release, on-sale, early-bird close, doors? If nothing was handed down, stop and route to samber/dev-event-organizer-skills@event-marketing-plan first; a page with no campaign calendar under it has no way to know what to show.
2. What is the funding model: priced, nominal, or free-to-attend with no registration at all? This decides the page's shape more than any other answer (see the branch below).
3. What are the positioning statement and the anti-positioning contrast sentence, word for word?
4. Is there a CFP, what are its open and close dates, and is the call on track for submissions or running short?
5. What does the ticket ladder look like - the rungs, what gates each one, and on what dates?
6. What accessibility target did the sibling set, and which surfaces did it put in scope?
7. First edition or recurring - and does a past-edition archive actually exist: photos, talk recordings, a speaker list, sponsor logos?
8. What is the doors date, and how many weeks of runway before the first campaign moment the page must be live for?
9. One edition's page, or a site meant to persist and be rebuilt each edition from the same structure?
10. Who builds and maintains this, for how many hours across the whole campaign - and can they change what the page shows on a date without a developer touching it?
11. What photo opt-out did the past edition's badges carry, and what do the speaker agreements permit for republishing its photographs and talk recordings?

Funding model

Who buys and who pays come apart on a conference ticket: an individual developer buys it, and an employer usually reimburses it. samber/dev-event-organizer-skills@event-ticket-pricing already splits its ladder on that, so an invoice rail reaches this page as a rung to present rather than as a page-shape decision.

The split leaves exactly one trace here: a short, linkable block the visitor forwards to whoever approves their travel budget. That is one section in the section set, not a branch.

What changes the whole page is whether there is anything to buy. Two published conference sites anchor the poles:

• Priced or nominal - PyCon US 2026 puts a hero with the name, dates and location above a single "Register Today!" button linking straight into the ticketing flow, followed by venue details and a conference-breakdown timeline. Exactly one primary action competes for attention anywhere on the page; no secondary CTA fights it. A ticketed, capacity-constrained conference is the closest this domain gets to the SaaS single-CTA rule being legitimate.
• Free-to-attend, no registration - FOSDEM 2026 has no CTA at all, because there is nothing to register for. Its hero substitutes scale and credibility signals for a value proposition - "8000+ hackers", "65 devrooms", "1013 lectures" - with the dates and location, then goes straight to the schedule, the video archive, news, sponsors and the venue. Its footer groups the practical cluster (accessibility, code of conduct, during-the-event, health policy) as its own block rather than scattering those links through the nav.

Forcing a "Register Now" button onto a page with nothing behind it is the wrong transfer from the SaaS rule. The free-event hero is a different shape, not a degraded version of the priced one. Read the funding model off Q2, which reads it off samber/dev-event-organizer-skills@event-ticket-pricing; never re-decide it here.

Workflow

1. Run the interview. Fix the dates, the message, the ladder and the accessibility target from Q1-Q6 before designing anything.
2. Branch on the funding model. A free, no-registration event skips every registration mechanic below rather than emptying it.
3. Restate the positioning statement and the anti-positioning sentence. Every headline below inherits both, unchanged. Where samber/dev-event-organizer-skills@event-positioning has genuinely refreshed the promise for this edition, show the old headline struck through beside the new one: a returning visitor reads a real pivot faster that way than from a rewritten paragraph. Use that device only for a pivot already decided, never as a substitute for deciding one.
4. Choose the page shape with the first menu. Whether the site is one page or ten decides which of the following steps have anywhere to put their output.
5. Build the section set for the chosen shape. Published section orders per funding model, the hero field list, and a negative example: references/page-shape-and-section-set.md. Write the FAQ against the procedural anxieties an applicant or attendee carries about this event's own mechanics: what it means to enter, when teams form, what happens if a rule is misunderstood. Skip the generic "what is this event" questions the rest of the page already answers.
6. Wire the date-gated CTA state machine with the second menu, then write the transition table: which CTA is on screen between which two dates. Table, the no-code fallback, and the structured-data block: references/cta-state-machine-and-structured-data.md.
7. Decide the reveal posture for every section whose content does not exist yet, with the third menu. This is a per-section decision, not one setting for the whole page.
8. Implement the accessibility target the sibling decided, in the build rather than after it: references/digital-accessibility-implementation.md.
9. Emit the structured-data block - a machine-readable name, description, dates, URL, image and location. Field list in the same reference as step 6.
10. Run the pre-launch gate in Measurement. All four binary checks pass, or the page does not go live.
11. Hand the post-click path to samber/dev-event-organizer-skills@event-attendee-email-sequences and the tracked per-channel links back to samber/dev-event-organizer-skills@event-marketing-plan. Say what you are handing over; do not write the emails.

If your harness has persistent memory, record the section set with the funding model that justified it, the CTA transition table with its real dates, which sections were withheld and why, and the accessibility scope. A recurring event rebuilds from that record instead of from a blank page, and next edition's dates are the only thing that actually changed.

Every ranking below is a default, not a law - it shifts with context and with who executes it. Re-rank all three menus against what you already know about this organizer: an existing site that persists across editions, a designer already on the team, a page nobody can edit without a developer, a badge photo opt-out most attendees took, an event that sells out on announcement. Each menu below names which interview answer moves which of its options.

Page shape

Ranked menu - questions a visitor gets answered per unit of build and upkeep effort. The rungs, the three orderings, the default and its promotion conditions are this skill's own construction, not measured thresholds. Dominance check: 4 rungs, 6 pairs, zero strict-dominance relations - clean by construction rather than by adjudication, and by-construction is never a pass.

Value and effort share one ordering, so one mechanism blocks all six pairs: the shape that answers more questions costs strictly more to build and keep, and no rung is ever at least equal on value while costing less. No third axis is printed here. The check can catch no misordering, so the efficiency line rests entirely on the arguments below rather than on anything it survived.

• effort (build hours, content to write, upkeep across the campaign): full multi-page site > front door plus the program set > front door plus practical annexes > one page

• value (questions answered, plus URLs other people can link to): full multi-page site > front door plus the program set > front door plus practical annexes > one page

• efficiency: front door plus practical annexes > one page > front door plus the program set > full multi-page site

• One page - a single scrolling page: name, dates, location, the positioning sentence, one CTA, the practical facts. Everything else is an anchor link.

• Front door plus practical annexes - the same front door, plus Location, Code of Conduct and Accessibility as their own addressable pages. The jump in value is not about length: an anchor is not an address. A code of conduct and an accessibility statement get cited by third parties, forwarded to employers, and pointed at by the siblings that wrote them. None of that works against a fragment on a scrolling page.

• Front door plus the program set - adds Program and Speakers as their own pages, with a page per talk and per speaker once the content is real.

• Full multi-page site - the whole DevOpsDays set as separate pages: welcome, program, speakers, sponsor, registration, propose, location, contact, diversity, conduct.

Default rung: front door plus practical annexes. Promotion condition (Q1 and Q4): move to the program set the moment the program is real - talks accepted, speakers confirmed - because the reveal is a dated campaign moment and it needs somewhere to land. Do not build those pages ahead of the content; that is what the third menu is for.

The starved option is the full multi-page site - top on value, top on effort, so efficiency never picks it. Promote it in two cases:

• Q9 says the site persists and gets rebuilt each edition, so the structure is paid for once and amortized across editions the way a per-year content directory is.
• A sponsorship agreement contracts a logo placement and a sponsor page becomes a fulfilment item owned by samber/dev-event-organizer-skills@event-sponsor-fulfillment, not an optional rung.

When Q10 says one volunteer with a handful of hours and no way to edit the page on a date, delete the two upper rungs outright and strike them from the axis lines above rather than leaving them as aspirations. A ten-page site with four empty pages is worse than one honest page, and a rung parked at the bottom of a menu reappears as scope in week three.

CTA posture

Ranked menu - visitors who take the action actually available today, per unit of setup and date-discipline effort. The rungs, the four orderings, the default and its promotion conditions are this skill's own construction, not measured thresholds. This one needed adjudication: one rung is dominated outright (contact-only beats the persistent button row on value at identical effort), and the efficiency line honours that.

• effort (setup, plus the discipline to keep it correct as dates pass): dual gated row > single date-gated primary > notify-me capture > persistent multi-CTA == contact only
• value (the visitor takes the one action open right now, and the page never sends anyone at a closed door): dual gated row > single date-gated primary > notify-me capture > contact only > persistent multi-CTA
• efficiency: single date-gated primary > dual gated row > notify-me capture > contact only > persistent multi-CTA
• compliance cost (review triggered, reversibility spent): notify-me capture > every other rung; the capture is the only one that collects personal data, so it needs a consent basis, a privacy notice and a deletion path before it ships. The four link-only rungs carry none.

The effort tie is argued: what costs effort on this menu is date-conditional logic, and neither the contact link nor a row of permanent buttons has any. Both are static markup written once and never touched again. They are equal in work and very unequal in value, which is exactly why contact-only outranks the button row on efficiency.

• Contact only - an organizer contact link and nothing else. In the DevOpsDays template this link is unconditional and present at every phase (layouts/partials/events/cta.html); it is also the honest whole menu for an event with nothing open yet.
• Notify-me capture - an email field so the announcement has somewhere to land before anything is for sale. Content Marketing World's landing page is a published example: a prominent notify-me box and sign-up section for the stretch before registration opens. samber/dev-event-organizer-skills@event-marketing-plan backs the rung from the other side, ranking the owned mailing list above every other channel and calling it worth building from zero.
• Single date-gated primary - at most one primary button on

...