Back to Details

event-marketing-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Event Marketing Plan

活动营销计划

You build the acquisition plan that fills a technical event: which audience segments get reached through which channels, at what weight, on what dates, against what per-phase targets. This is the umbrella plan. It decides when and how much each channel gets and hands the channel's own content to the sibling that owns it.
Four inputs arrive already decided. Do not re-derive them:
  • The message - 
    samber/dev-event-organizer-skills@event-positioning
    supplies the promise and the audience definition every channel's copy carries.
  • The demand read - 
    samber/dev-event-organizer-skills@event-market-fit
    supplies whether there is an audience at all, and is diagnostic where this plan is prescriptive.
  • The dates - 
    samber/dev-event-organizer-skills@event-ticket-pricing
    sets the price points and the early-bird cutoff. Those cutoffs are fixed calendar moments this plan reacts to; this skill never moves one to make a campaign more convenient.
  • Two channels' deal mechanics - 
    samber/dev-event-organizer-skills@cross-event-promotion
    and 
    samber/dev-event-organizer-skills@event-media-partnerships
    own how those barter deals are sourced and structured. This plan only weights and schedules them.
Two organizer guides ground this plan:
  • DevOpsDays' organizer guide names five acquisition channels and calls a mailing list "a powerful tool for ticket sales".
  • MLH's organizer guide catalogs campus tactics and publishes a signup-to-attendance drop-off rate.
Both publish checkpoint numbers for total registrations, and both stop there: the funnel as a whole carries published figures, a single channel's yield in registrations does not. So when presenting the plan, say which targets are which:
  • Whole-funnel checkpoints: published.
  • Channel value ordering: your judgement.
  • Per-channel targets: set from scratch.
Every ranking below is a default, not a law: it shifts with context and with who executes it. After the interview, re-rank both menus against what you already know about this organizer. Each of these overturns a default rung:
  • An existing large mailing list.
  • An organizer with a popular newsletter or podcast.
  • A single-campus audience.
  • A sponsor who bundles ad credits.
  • A volunteer team with zero content-production capacity.
你构建的获取计划用于填满一场技术活动：哪些受众细分通过哪些渠道触达，以什么权重，在哪些日期，对应哪些阶段目标。这是一个总括性计划。它决定每个渠道在何时获得多少资源，并将渠道自身的内容交给拥有它的兄弟技能。
四个输入已经在别处决定。不要重新推导它们：
  • 信息 - 
    samber/dev-event-organizer-skills@event-positioning
    提供每个渠道文案所承载的承诺和受众定义。
  • 需求判断 - 
    samber/dev-event-organizer-skills@event-market-fit
    提供是否存在受众，并且在本文档是规定性时，它是诊断性的。
  • 日期 - 
    samber/dev-event-organizer-skills@event-ticket-pricing
    设定价格点和早鸟截止日期。这些截止日期是固定的日历时刻，本计划需应对；此技能绝不会为了活动便利而移动它们。
  • 两个渠道的交易机制 - 
    samber/dev-event-organizer-skills@cross-event-promotion
    和 
    samber/dev-event-organizer-skills@event-media-partnerships
    负责这些以物易物交易的来源和结构。本计划仅对它们进行加权和排期。
两个组织者指南为本计划提供基础：
  • DevOpsDays 的组织者指南列出了五个获取渠道，并称邮件列表是“门票销售的强大工具”。
  • MLH 的组织者指南列出了校园策略，并发布了从报名到出席的流失率。
两者都发布了总注册数的检查点数字，并且都止步于此：整个漏斗有公开数据，单个渠道的注册产出则没有。因此在呈现计划时，要说明哪些目标是哪种：
  • 整个漏斗的检查点：已发布。
  • 渠道价值排序：你的判断。
  • 每个渠道的目标：从零开始设定。
下面的每个排名都是默认值，而非法则：它们会随上下文和执行者而变化。在访谈之后，根据你对该组织者已知的信息重新排列两个菜单。以下每一项都会推翻默认等级：
  • 一个已有的庞大邮件列表。
  • 一个拥有热门时事通讯或播客的组织者。
  • 单校园受众。
  • 一个捆绑广告积分的赞助商。
  • 一个完全没有内容生产能力的志愿者团队。

Interview

访谈

Ask one question at a time, multiple-choice where possible.
Questions 4 and 7-9 exist because the channel and budget menus diverge sharply on time-to-effect, durability and effort; the default order cannot be picked for the user. Q4 carries the deadline axis: doors are the hard date. A short runway between announcement and doors promotes fast-acting rungs (paid ads, a partner's next send) over slow ones (building a list from zero, local relationship-building), which cannot repay inside one compressed cycle.
  1. Ticketed (paid) or free registration? This picks the calendar spine, and it is the single most consequential answer in the interview.
  2. Community-run or company/vendor-run? The channel economics differ (see the next section).
  3. What is the target number - expected paid ticket sales, or an attendance goal? For a ticketed event, ask for expected sales net of sponsor, speaker, organizer and volunteer comps; those tickets never had to be sold.
  4. Which dates are already fixed: announcement, early-bird close, CFP close, speaker announcement, full-agenda announcement, doors? Collect them before planning anything.
  5. Where does the target audience already read, listen and gather - which lists, communities, meetups, campuses, employers? Name real properties; this settles the channel weights and breaks the value ties below.
  6. What does the event already own: a mailing list and its size, social accounts and their reach, a prior edition's own sales curve, an existing partner roster?
  7. Is there a cash acquisition budget at all, and who approves it? A community event funded ~80%+ by sponsorship spends acquisition money against catering, not against a marketing line.
  8. One edition's push, or a compounding asset across editions? A compounding mandate promotes the slow rungs (list building, local presence, partner relationships) that a single edition never repays.
  9. What is the effort ceiling - organizer hours per week, who writes, who shows up in person?
  10. Is the edition in person, online-only, or hybrid?
一次问一个问题，尽可能提供选择题。
问题4和7-9存在是因为渠道和预算菜单在见效时间、持久性和工作量上差异很大；默认顺序无法替用户选择。Q4带来截止日期轴：活动开场是硬性日期。从公告到开场的时间窗口短，会促进快速见效的等级（付费广告、合作伙伴的下一次发送），而不是慢速的（从零建立列表、本地关系建设），后者无法在一个压缩周期内收回成本。
  1. 售票（付费）还是免费注册？这决定了日历主线，并且是整个访谈中最有影响力的答案。
  2. 社区运营还是公司/供应商运营？渠道经济学不同（见下一节）。
  3. 目标数字是多少——预期付费门票销售，还是出席目标？对于售票活动，询问扣除赞助商、演讲者、组织者和志愿者免费票后的净预期销售；这些票不需要被销售。
  4. 哪些日期已经固定：公告、早鸟截止、CFP截止、演讲者公告、完整议程公告、开场？在计划任何事项之前收集它们。
  5. 目标受众已经在哪些地方阅读、收听和聚集——哪些列表、社区、meetup、校园、雇主？命名真实属性；这决定了渠道权重并打破下面的价值平局。
  6. 活动已经拥有什么：邮件列表及其规模、社交媒体账号及其覆盖范围、往届活动的销售曲线、现有的合作伙伴名单？
  7. 是否有现金获取预算，谁批准？一个约80%以上由赞助资助的社区活动，其获取费用是针对餐饮而非营销线支出的。
  8. 一届的推动，还是跨届的复利资产？复利任务会促进慢速等级（列表构建、本地存在、合作伙伴关系），而这些是一届活动永远无法收回的。
  9. 工作量上限是多少——组织者每周小时数、谁负责写作、谁亲自出席？
  10. 本届活动是线下、纯线上还是混合形式？

Community-run vs company-run

社区运营 vs 公司运营

The buyer of a conference ticket is an individual developer whose employer often pays, so every event straddles employer-funded and self-funded attendance. The axis that actually changes the plan is who owns the event - the same axis this collection's positioning and sponsor skills argue:
  • Community-run - the community-run organizer guides define the checkpoints and channel taxonomy used here. Acquisition is mostly owned and barter channels because cash competes with the event's own costs, and reciprocal-visibility swaps replace paid placement.
  • Company/vendor-run - the community organizer guides are written for community events, so extrapolate rather than cite them at this pole. Expect a real budget line, a marketer who owns it, paid channels that a community event cannot reach, and media properties routing vendor promotion through commercial ad inventory rather than barter. The calendar spines still apply unchanged; only the budget posture moves.
Say which pole the plan assumes before allocating anything.
会议门票的购买者是个人开发者，其雇主通常支付费用，因此每个活动都横跨雇主资助和自费出席。真正改变计划的是活动的所有者——这与本系列中的定位和赞助技能所论证的轴线相同：
  • 社区运营 - 社区运营的组织者指南定义了这里使用的检查点和渠道分类。获取主要依靠自有和以物易物渠道，因为现金与活动自身成本竞争，互惠可见度交换取代付费位置。
  • 公司/供应商运营 - 社区组织者指南是为社区活动编写的，因此在这一端应进行外推而非引用。可以预期有真正的预算线、负责它的营销人员、社区活动无法触达的付费渠道，以及通过商业广告库存而非以物易物来路由供应商推广的媒体属性。日历主线仍然适用不变；只有预算姿态发生变化。
在分配任何资源之前，说明计划假定的立场。

Pick the calendar spine - never blend the two

选择日历主线——绝不混合两者

Two calendar spine types exist. They measure different denominators and belong to structurally different events. Averaging them, or carrying a checkpoint from one into the other, produces targets that are wrong in both directions.
  • Ticketed conference → percent of expected ticket sales (DevOpsDays organizing guide). Checkpoints sit at named marketing moments, not fixed calendar offsets, because sales spike at announcements. The risk being managed is under-selling.
  • Free event → percent of the attendance goal (MLH hackathon organizer guide). Checkpoints sit at fixed offsets (2 weeks, 1 week) and the target exceeds 100% on purpose. The risk being managed is no-shows, not under-selling.
Full checkpoint ladders, the worked numbers behind both, and the phase-target method: references/calendar-spines-and-phase-targets.md.
This choice is deliberately not ranked. The two spines are not competing options with different value per unit of effort - they are descriptions of two different demand shapes, and the event's revenue and no-show structure picks one outright. Ranking them would be false precision: the "more efficient" spine is simply the one measuring the wrong thing for that event.
For the in-between case - a nominal-fee event, or a free event with a hard capacity cap - pick the spine by the failure you actually fear: unsold seats or empty seats. Run it as the plan's only target line. Read the other spine's checkpoint as a secondary sanity check that never enters a target.
存在两种日历主线。它们衡量不同的分母，并且属于结构上不同的活动。对它们取平均值，或将一个的检查点带入另一个，会产生两个方向都错误的目标。
  • 售票会议 → 预期门票销售的百分比（DevOpsDays 组织指南）。检查点位于具名的营销时刻，而非固定的日历偏移，因为公告时会引发销售高峰。所管理的风险是销售不足。
  • 免费活动 → 出席目标的百分比（MLH 黑客马拉松组织指南）。检查点位于固定偏移（2周、1周），并且目标故意超过100%。所管理的风险是缺席，而非销售不足。
完整的检查点阶梯、两者背后的计算数字以及阶段目标方法：参见 references/calendar-spines-and-phase-targets.md。
这个选择故意不进行排名。两条主线并不是单位努力价值不同的竞争选项——它们是对两种不同需求形态的描述，而活动的收入和缺席结构直接选择其一。对它们排名将是虚假的精确：“更高效”的主线只是衡量了该活动错误指标的那一条。
对于介于两者之间的情况——象征性收费的活动，或有硬性容量上限的免费活动——根据你实际担心的失败来选择主线：未售出的座位还是空座位。将其作为计划唯一的目标线。将另一条主线的检查点作为次要的合理性检查，绝不进入目标。

Workflow

工作流程

  1. Run the interview. Fix the spine (Q1), the pole (Q2), the target number net of comps (Q3), and the fixed dates (Q4).
  2. Restate the message and the demand read from 
    samber/dev-event-organizer-skills@event-positioning
    and 
    samber/dev-event-organizer-skills@event-market-fit
    in one paragraph each. If either is missing, stop and route there first - a channel plan for an undefined audience allocates effort at random.
  3. Map audience segments to channels from the Q5 answers, then weight them with the ranked menu below. Name the segment each channel is bought for.
    • One segment can need several channels.
    • One channel can serve several segments.
  4. Lay the spine's checkpoints on the calendar, then pin every fixed date from Q4 onto it. Work backward from doors, not forward from today. Earliest anchor: T-7 months, "ensure marketing is off and running" (DevOpsDays organizer guide).
  5. Allocate budget with the posture menu below. The percentage allocation table comes from B2B / B2C SaaS conventions, not from event-industry practice. Say so explicitly when showing it, so nobody reads a borrowed convention as an events standard.
  6. Set funnel targets per phase against the spine's checkpoints, never against a straight line. Method and worked example: references/calendar-spines-and-phase-targets.md.
  7. Route each channel to the sibling that executes it (see References). Hand over the weight, the phase, and the dates. Do not write the sibling's content here.
  8. Re-forecast at each checkpoint against the plan's own line, and diagnose a miss before reacting to it (see Measurement).
If your harness has persistent memory, record for each edition:
  • The spine chosen and why.
  • The target net of comps.
  • The channel weights, with the segment each was bought for.
  • The fixed dates.
  • The budget posture.
  • Each checkpoint's planned-vs-actual.
The next edition's plan starts from a real prior curve instead of a blank calendar, which is exactly what the pace-index method needs.
  1. 进行访谈。确定主线（Q1）、立场（Q2）、扣除免费票后的目标数字（Q3）以及固定日期（Q4）。
  2. 用一段话分别复述 
    samber/dev-event-organizer-skills@event-positioning
    和 
    samber/dev-event-organizer-skills@event-market-fit
    提供的信息和需求判断。如果任一缺失，停下来并先路由到那里——为未定义的受众制定的渠道计划等于随意分配努力。
  3. 根据Q5的答案将受众细分映射到渠道，然后用下面的排名菜单对其进行加权。说明每个渠道是为哪个细分购买的。
    • 一个细分可能需要多个渠道。
    • 一个渠道可以服务多个细分。
  4. 将主线的检查点放在日历上，然后把Q4中的每个固定日期固定到上面。从开场向前倒推，而不是从今天向前。最早锚点：T-7个月，“确保营销已启动并运行”（DevOpsDays 组织指南）。
  5. 使用下面的姿态菜单分配预算。百分比分配表来自B2B/B2C SaaS惯例，而非活动行业实践。展示时明确说明，以免有人将借用来的惯例误读为活动标准。
  6. 基于主线的检查点设置每个阶段的漏斗目标，绝不针对直线。方法和计算示例：参见 references/calendar-spines-and-phase-targets.md。
  7. 将每个渠道路由到执行它的兄弟技能（见参考）。移交权重、阶段和日期。不要在这里编写兄弟技能的内容。
  8. 在每个检查点根据计划自身的线重新预测，并在反应之前诊断偏差（见衡量）。
如果你的环境有持久记忆，请为每届活动记录：
  • 选择的主线及其原因。
  • 扣除免费票后的目标。
  • 渠道权重，以及每个渠道被购买所服务的细分。
  • 固定日期。
  • 预算姿态。
  • 每个检查点的计划与实际对比。
下一届活动的计划从真实的先前曲线开始，而不是空白日历，这正是节奏指数方法所需要的。

Channel mix

渠道组合

Ranked menu: value returned per unit of organizer effort, drawn from DevOpsDays' five-channel visibility taxonomy and MLH's campus and social tactic catalog. The value ranking is judgement rather than a measured benchmark. Re-rank it against what this organizer already owns.
Channel taxonomy, quotes from the guides, campus-scale tactics and the owned/earned/paid framing: references/channel-menu-and-budget-allocation.md.
  • effort (organizer hours, coordination, recurrence): 
    local and campus engagement > partner channels > own social presence > paid ads == pre-event press > own mailing list > comms hub
  • value (registrations bought, judged not measured): 
    own mailing list > local and campus engagement == partner channels > own social presence > paid ads > pre-event press > comms hub
  • efficiency: 
    own mailing list > comms hub > partner channels > paid ads > local and campus engagement > own social presence > pre-event press
  • compliance cost (review triggered, reversibility lost): 
    paid ads > own mailing list > partner channels
The other four channels carry no compliance cost of their own: posting on your own accounts, showing up at a meetup, publishing a link hub and pitching a local outlet touch no consent record, no signed agreement and no spend approval.
Both ties are argued:
  • Effort tie (paid ads == pre-event press): a paid-ads run and a press pitch are each a few hours of setup or writing followed by waiting on someone else's system. Neither is a standing job the way social posting is.
  • Value tie (local engagement == partner channels): both put the event in front of an audience someone has already assembled and that already trusts the assembler. The difference is whether an organizer shows up in person or a partner's channel does it for them, not how much reach is bought.
Compliance cost is real on exactly three rungs:
  • Paid ads need an ad account in the organization's name, platform ad-policy review and someone authorized to commit the spend.
  • Own mailing list carries consent exposure: a list collected for one edition, mailed for the next, without a documented opt-in, is the one acquisition asset that can force a deletion the event cannot undo.
  • Partner channels carry logo-licensing and delivery terms, handled in 
    samber/dev-event-organizer-skills@cross-event-promotion
    and 
    samber/dev-event-organizer-skills@event-media-partnerships
    .
Each channel in full:
  • Own mailing list - announcements of ticket availability, early-bird offers, agenda releases, countdowns. DevOpsDays' guide: "Keep emails informative and limit their frequency to maintain engagement." Worth building from zero if the event has none. Where last edition's registration form recorded who said they were not available that year, re-contact that specific segment at this edition's announcement - a "not available last time, are you free now" ask converts a list segment other channels never reach.
  • Comms hub - one page centralizing every channel, shareable by QR code (DevOpsDays organizer guide). One-time build. It converts reach the other channels create rather than creating reach itself, which is why it sits low on value and high on efficiency at once. This plan owns the page; 
    samber/dev-event-organizer-skills@event-comms-channels
    supplies the per-channel roster (name, job, owner, hours) it publishes.
  • Partner channels - cross-event swaps, media and community partners, developer-ambassador programs. Executed by 
    samber/dev-event-organizer-skills@cross-event-promotion
    and 
    samber/dev-event-organizer-skills@event-media-partnerships
    ; this plan sets their weight and phase.
  • Paid ads - targeted social ads. MLH's guide describes them as "cheap and effective" for campus audiences (note: that claim is specific to campus scale, not general).
  • Local and campus engagement - meetups, local employers, business associations (DevOpsDays); in-class pitches, tabling, flyering, student groups and departments, plus the "at least 3 schools within 6 hours" invitation rule (MLH). Treat business-support networks/incubators and named school contacts as two separate referrer pools rather than one undifferentiated local list - they run on different outreach cadences and are worth tracking apart so each pool's own conversion stays legible.
  • Own social presence - regular posting across the event's accounts, varying times. Weighted below its intuitive place on purpose: DevOpsDays' guide names the problem directly, "with the dispersal of tech communities from Twitter, a lot of community events are struggling to reach people."
  • Pre-event press - school paper, local outlets, community media (MLH). A lighter ask than a press campaign; a real one belongs to 
    samber/dev-event-organizer-skills@event-press-relations
    .
Where to start:
  • Default rung: own mailing list plus comms hub, with own social presence running underneath as the baseline.
  • Promotion condition: add partner channels once Q5 names properties whose audience genuinely matches, and add paid ads only after one owned channel shows a tracked referral signal worth amplifying, never as the first move against a soft checkpoint.
The starved option is local and campus engagement: high value, highest effort, so efficiency never picks it. Promote it anyway in two cases:
  • A first edition with no list to mail, where the top rung is simply empty.
  • A geographically concentrated audience (one campus, one metro), where in-person presence reaches a share of the target no owned channel can.
The organizer guides argue for it directly. DevOpsDays states "avoid the misconception that a great agenda alone will attract attendees. Actively promote your event," and MLH treats flyering and in-class pitches as core rather than optional.
Delete condition, keyed to Q10: for an online-only edition, delete the in-person half of local engagement rather than demoting it - the meetup and community relationships survive online, the tabling and flyering do not. A deleted rung cannot quietly reappear as scope in week three.
排名菜单：每单位组织者努力返回的价值，来自DevOpsDays的五渠道可见性分类和MLH的校园及社交策略目录。价值排名是判断而非测量基准。根据该组织者已拥有的资源重新排序。
渠道分类、指南引文、校园规模策略以及自有/赢得/付费框架：参见 references/channel-menu-and-budget-allocation.md。
  • 努力（组织者小时数、协调、重复性）： 
    本地与校园参与 > 合作伙伴渠道 > 自有社交存在 > 付费广告 == 活动前媒体 > 自有邮件列表 > 通讯枢纽
  • 价值（购买的注册数，判断而非测量）： 
    自有邮件列表 > 本地与校园参与 == 合作伙伴渠道 > 自有社交存在 > 付费广告 > 活动前媒体 > 通讯枢纽
  • 效率： 
    自有邮件列表 > 通讯枢纽 > 合作伙伴渠道 > 付费广告 > 本地与校园参与 > 自有社交存在 > 活动前媒体
  • 合规成本（触发的审查、失去的可撤销性）： 
    付费广告 > 自有邮件列表 > 合作伙伴渠道
其他四个渠道没有自身的合规成本：在自己的账号发帖、出现在meetup、发布链接枢纽和联系本地媒体不涉及同意记录、不涉及签署协议、不涉及支出批准。
两个平局均有论证：
  • 努力平局（付费广告 == 活动前媒体）：一次付费广告投放和一次媒体投稿各自是几小时的设置或写作，然后等待他人的系统。两者都不是像社交发帖那样的持续性工作。
  • 价值平局（本地参与 == 合作伙伴渠道）：两者都将活动呈现在某人已经聚集并信任其组织者的受众面前。区别在于组织者亲自出现还是合作伙伴的渠道代为完成，而不是购买了多少覆盖。
合规成本在恰好三个等级上是真实的：
  • 付费广告 需要以组织名义开设广告账户、平台广告政策审查以及被授权支出的人。
  • 自有邮件列表 带有同意风险：为一个版本收集的列表，在下一次活动中发送邮件，如果没有文件化的选择加入，这是唯一可能迫使无法撤销的删除的获取资产。
  • 合作伙伴渠道 带有标志许可和交付条款，由 
    samber/dev-event-organizer-skills@cross-event-promotion
    和 
    samber/dev-event-organizer-skills@event-media-partnerships
    处理。
每个渠道的完整描述：
  • 自有邮件列表 - 票务可用性公告、早鸟优惠、议程发布、倒计时。DevOpsDays指南：“保持邮件内容丰富，限制频率以维持参与度。”如果活动没有列表，值得从零建立。如果往届注册表记录了当时表示当年无法参加的人，在本届公告时重新联系该特定细分——“上次没空，这次有空吗”的提问会转化其他渠道无法触达的列表细分。
  • 通讯枢纽 - 一个集中所有渠道的页面，可通过QR码分享（DevOpsDays组织指南）。一次性构建。它转化其他渠道创造的覆盖，而不是自身创造覆盖，这就是为什么它价值低但效率高。本计划拥有该页面；
    samber/dev-event-organizer-skills@event-comms-channels
    提供它发布的每个渠道名册（名称、任务、负责人、时间）。
  • 合作伙伴渠道 - 跨活动互换、媒体和社区合作伙伴、开发者大使计划。由 
    samber/dev-event-organizer-skills@cross-event-promotion
    和 
    samber/dev-event-organizer-skills@event-media-partnerships
    执行；本计划设定它们的权重和阶段。
  • 付费广告 - 定向社交广告。MLH指南将其描述为针对校园受众“廉价而有效”（注意：该说法特定于校园规模，并非普遍适用）。
  • 本地与校园参与 - meetup、本地雇主、商业协会（DevOpsDays）；课堂宣讲、摆摊、发传单、学生组织和院系，以及“6小时内至少3所学校”的邀请规则（MLH）。将商业支持网络/孵化器和具名的学校联系人视为两个独立的推荐源池，而非一个未区分的本地列表——它们的推广节奏不同，值得分开跟踪，以便每个池的转化率保持清晰。
  • 自有社交存在 - 在活动的各个账号上定期发帖，时间多样化。故意将其权重置于直觉位置之下：DevOpsDays指南直接指出了问题，“随着技术社区从Twitter分散，很多社区活动难以触达人群。”
  • 活动前媒体 - 校报、本地媒体、社区媒体（MLH）。比新闻发布活动的请求更轻；真正的新闻发布属于 
    samber/dev-event-organizer-skills@event-press-relations
    。
从哪里开始：
  • 默认等级：自有邮件列表加通讯枢纽，自有社交存在作为基线在其下方运行。
  • 升级条件：一旦Q5命名了受众真正匹配的属性，就添加合作伙伴渠道；只有在自有渠道显示出值得放大的可追踪推荐信号后才添加付费广告，绝不在软检查点之前作为第一步。
被忽视的选项是本地与校园参与：高价值、最高努力，所以效率永远不会选择它。在两种情况下仍要提升它：
  • 没有可投递列表的首届活动，最高等级为空。
  • 地理上集中的受众（一个校园、一个都市区），实体存在能触达的自有渠道无法达到的份额。
组织者指南直接论证了这一点。DevOpsDays指出“避免‘仅凭出色的议程就能吸引与会者’的误解。积极推广你的活动”，MLH将发传单和课堂宣讲视为核心而非可选。
删除条件，与Q10相关：对于纯线上活动，删除本地参与中线下的一半，而不是降级——meetup和社区关系在线上存活，摆摊和发传单则不能。删除的等级不能在第三周悄悄作为范围重新出现。

Budget allocation posture

预算分配姿态

Ranked menu - registrations bought per unit of money-handling and approval effort. Postures and the percentage table behind the full spread: references/channel-menu-and-budget-allocation.md.
  • effort (planning, approvals, reconciliation, monitoring): 
    full spread > concentrated bet > fixed test budget > barter-only
  • value (reach bought, judged): 
    concentrated bet == full spread > fixed test budget > barter-only
  • efficiency: 
    barter-only > fixed test budget > concentrated bet > full spread
  • compliance cost: 
    full spread == concentrated bet > fixed test budget
Barter-only carries no compliance cost of its own: its exposure is the partner agreement, owned by the two partner-channel skills named above.
Both ties are argued:
  • Value tie (concentrated bet == full spread): both deploy the same money and buy comparable total reach. The spread hedges channel uncertainty, the bet compounds one channel's learning. They differ in variance, not in expected value.
  • Compliance cost tie (full spread == concentrated bet): both cross whatever threshold triggers treasurer or finance sign-off and an ad account held in the organization's name, while a capped test budget usually clears under one organizer's own discretion.
Each posture in full:
  • Barter-only - everything through owned channels and reciprocal-visibility swaps. No cash, no approvals.
  • Fixed test budget - one capped amount, one paid channel, one measurable question.
  • Concentrated bet - the bulk of available cash into the single highest-confidence channel.
  • Full spread - a balanced percentage allocation across paid, content, partner and testing lines (not an event-industry standard; derived from SaaS marketing practice).
Where to start:
  • Default rung: barter-only plus a fixed test budget, for a community-run event.
  • Promotion condition: move to a concentrated bet when a checkpoint misses and one channel already shows a tracked referral signal worth scaling. A miss alone is a reason to diagnose, not to spend.
The starved option is the full spread - its effort and approval load mean efficiency never picks it. Promote it for a company-run event with a standing marketing budget line and a marketer who owns reporting on it: there, the spread's hedging is worth its overhead, and the overhead is someone's actual job.
Where there is no cash at all - no acquisition line and no discretionary float - delete the three spending postures rather than parking them at the bottom. Barter-only is then the whole menu, and a rung nobody can fund does not get to reappear as a plan B the first time a checkpoint misses.
排名菜单——每单位资金处理和批准努力所购买的注册数。姿态和完整分布的百分比表：参见 references/channel-menu-and-budget-allocation.md。
  • 努力（规划、批准、对账、监控）： 
    全面铺开 > 集中押注 > 固定测试预算 > 仅以物易物
  • 价值（购买的覆盖，判断）： 
    集中押注 == 全面铺开 > 固定测试预算 > 仅以物易物
  • 效率： 
    仅以物易物 > 固定测试预算 > 集中押注 > 全面铺开
  • 合规成本： 
    全面铺开 == 集中押注 > 固定测试预算
仅以物易物没有自身的合规成本：其风险是合作协议，由上面提到的两个伙伴渠道技能负责。
两个平局均有论证：
  • 价值平局（集中押注 == 全面铺开）：两者部署相同的资金并购买可比的总覆盖。铺开对冲渠道不确定性，押注复合单一渠道的学习。它们差异在方差，而非期望值。
  • 合规成本平局（全面铺开 == 集中押注）：两者都越过触发财务主管或财务签字以及以组织名义持有的广告账户的阈值，而有上限的测试预算通常可在单个组织者的自行决定下通过。
每个姿态的完整描述：
  • 仅以物易物 - 一切通过自有渠道和互惠可见度交换。无现金、无批准。
  • 固定测试预算 - 一个有上限的金额、一个付费渠道、一个可测量的问题。
  • 集中押注 - 将大部分可用现金投入单一高置信度渠道。
  • 全面铺开 - 在付费、内容、合作伙伴和测试线上进行平衡的百分比分配（不是活动行业标准；源自SaaS营销实践）。
从哪里开始：
  • 默认等级：仅以物易物加固定测试预算，用于社区运营活动。
  • 升级条件：当检查点未达标 并且 一个渠道已显示出值得扩展的可追踪推荐信号时，转向集中押注。单独的未达标是诊断的理由，而不是支出的理由。
被忽视的选项是全面铺开 - 其努力和批准负担意味着效率永远不会选择它。对于有固定营销预算线和负责报告的营销人员的公司运营活动，提升它：在那里，铺开的对冲价值值得其开销，而开销是某人的实际工作。
在没有现金的情况下——没有获取线、没有可自由支配资金——删除三个花钱的姿态，而不是将它们放在底部。仅以物易物就是整个菜单，而没人能资助的等级不能作为计划B在第一次检查点未达标时重新出现。

Failure modes

失败模式

  • Blending the two spines. "200% of goal" and "40-50% of expected sales" are percentages of different denominators, one of an attendance goal and one of net-of-comps expected sales. Averaging them, or carrying MLH's 2-weeks-out rule onto a paid conference, sets a target that is unreachable or trivially met and tells you nothing either way. Pick one spine, state which, and keep the other out of the target line.
  • Setting the early-bird date here. The cutoff arrives fixed from 
    samber/dev-event-organizer-skills@event-ticket-pricing
    . Moving it to smooth a campaign changes the price ladder and the event's revenue, and the pricing skill's own checkpoint no longer means what it measured. Plan around the date. If it genuinely must move, route the decision back rather than absorbing it.
  • Doing a sibling's job. Writing the announcement email, designing the registration page, or building the social content calendar inside this plan produces a second, competing version of work the sibling owns. Hand over weight, phase and dates. Stop there.
  • Treating the free-event drop-off as universal. The 30-50% signup-to-attendance drop-off is MLH's, for free hackathons, and it is exactly why that spine targets 200%. A paid ticket has its own, much smaller no-show behavior, and its rate is self-set per event. Never apply the free-event over-registration multiple to a paid conference.
  • Presenting the budget percentages as an event standard. They come from SaaS marketing practice, not from event-industry benchmarking. Shown unlabeled, they read as an event-industry standard the reader will defend to a board that has no reason to accept them. Label them explicitly.
  • Reading launch week as demand. The announcement spike measures reach, not demand. Week two is when the campaign pattern becomes readable. A quiet middle is the normal shape of the curve, not a failure signal.
  • Starting marketing when the program is locked. DevOpsDays' guide warns directly: "avoid the misconception that a great agenda alone will attract attendees." The documented earliest start point is T-7 months, well before most programs finalize.
  • 混合两条主线。“目标的200%”和“预期销售的40-50%”是不同分母的百分比，一个是出席目标，一个是扣除免费票后的预期销售。对它们取平均值，或将MLH的2周规则套用到付费会议上，会设置一个无法达到或轻易达到的目标，无论哪种都告诉你任何东西。选择一条主线，说明是哪条，并将另一条排除在目标线之外。
  • **在此处设置早鸟日期。**截止日期由 
    samber/dev-event-organizer-skills@event-ticket-pricing
    固定提供。为了平滑活动而移动它会改变价格阶梯和活动收入，定价技能自身的检查点不再意味着其测量的内容。围绕日期进行规划。如果它确实必须移动，将决策路由回去而不是吸收它。
  • **做兄弟技能的工作。**在本计划中编写公告邮件、设计注册页面或构建社交内容日历，会产生兄弟技能拥有的工作的第二个竞品版本。移交权重、阶段和日期。到此为止。
  • **将免费活动的流失视为普遍。**30-50%的报名到出席流失是MLH的，是针对免费黑客马拉松的，这正是该主线以200%为目标的原因。付费门票有其自身小得多的缺席行为，其比率由每个活动自行设定。绝不要将免费活动的过度注册倍数应用于付费会议。
  • **将预算百分比呈现为活动标准。**它们来自SaaS营销实践，而非活动行业基准。不加标签地展示，它们会被读作活动行业标准，读者会向没有理由接受它们的董事会辩护。明确标注它们。
  • **将发布周解读为需求。**公告峰值衡量的是覆盖，而非需求。第二周活动模式才开始可读。中间的平静是曲线的正常形状，不是失败信号。
  • **在节目锁定后才开始营销。**DevOpsDays指南直接警告：“避免‘仅凭出色的议程就能吸引与会者’的误解。”文档记录的最早开始点是T-7个月，远早于大多数节目确定。

Measurement

衡量

Channel attribution is the honest weak point: the whole-funnel checkpoints carry published benchmarks, every channel-level target is yours to set. Published event figures measure the funnel, not a channel's contribution to it, so a per-channel number is only ever as good as the tracked link behind it. Before launching, write down what each signal would trigger.
  • Checkpoint hit or miss against the chosen spine: the only externally grounded target line in the plan. Ladders and figures: references/calendar-spines-and-phase-targets.md.
  • The execution-vs-demand discriminator (ticketed spine): roughly 40-50% of expected sales one month out is on track. A team that skipped or delayed its visibility push lands nearer 25-30% at the same point (DevOpsDays). A miss in that band is a marketing-execution problem, not proof of missing demand - diagnose before concluding, because the two have opposite fixes. Before reading a shortfall as weak demand, check three communication causes specifically: program or speaker announcements that ran later than planned, a theme narrow enough to exclude part of the intended audience, and messaging that never actually said who is welcome - the last of these is a funnel problem worth naming outright rather than a vague "we should promote more" diagnosis.
  • Pace index against the event's own prior curve: tickets-to-date divided by curve-expected, times 100. Above 100 is running hot, below 100 is a gap with a size and a deadline attached. It needs a prior curve, which is why step 8's memory record matters.
  • Per-channel referral signal: a distinct tracked link or registration code per channel, decided before launch because it cannot be added retroactively. A channel at zero across two editions loses its weight next edition. Where a partner channel serves several distinct closed communities (a school, a professional group), give each its own code rather than one shared partner-channel code: it tracks which specific community actually converts, and it reads to that community as an invitation made for them rather than a generic discount.
  • Funnel demographics beyond headcount (self-set, judged not a benchmark): role mix, geography, and one figure most plans skip - whether registering costs the attendee something real beyond the ticket price, such as time off work the next business day. A signup form that only asks role checkboxes filters cheaply but excludes anyone who fits no listed label; if that trade-off is made deliberately, invest the effort saved into messaging (who is welcome, what a typical attendee looks like) rather than leaving the exclusion unaddressed, and widen the checkbox list from the first edition rather than patching it in later once a gap is visible.
  • Self-reported source on the registration form: "how did you hear about us" undercounts owned channels and double-counts whatever the registrant saw last. Useful only as a cross-check against tracked links, never as the primary attribution.
  • Reach-versus-conversion split (self-set diagnostic): healthy traffic to the registration page with low conversion points at the price or the page, not at the channel mix - route to 
    samber/dev-event-organizer-skills@event-ticket-pricing
    or 
    samber/dev-event-organizer-skills@event-landing-page
    rather than buying more reach.
渠道归因是诚实的弱点：**整个漏斗的检查点有已发布的基准，每个渠道级目标是你自己设定的。**已发布的活动数据衡量漏斗，而非单个渠道对漏斗的贡献，所以每个渠道的数字只与其背后的可追踪链接一样好。在启动前，写下每个信号会触发什么。
  • 针对所选主线的检查点命中或未命中：计划中唯一外部锚定的目标线。阶梯和数字：参见 references/calendar-spines-and-phase-targets.md。
  • 执行与需求区分器（售票主线）：距活动约一个月时，预期销售的大约40-50%是在轨道上。跳过了或延迟了可见性推动的团队在同一时点更接近25-30%（DevOpsDays）。该区间的未达标是营销执行问题，而非需求缺失的证据——先诊断再下结论，因为两者的修复方向相反。在将短缺解读为需求疲软之前，具体检查三个沟通原因：程序或演讲者公告晚于计划、主题过于狭窄排除了部分预期受众、以及信息从未真正说明谁受欢迎——最后一个是值得直接指出的漏斗问题，而非模糊的“我们应该多推广”的诊断。
  • 相对于活动自身先前曲线的节奏指数：截至当前的票数除以曲线预期，乘以100。高于100是运行过热，低于100是带有大小和截止日期的缺口。它需要先前的曲线，这就是步骤8的记忆记录重要的原因。
  • 每个渠道的推荐信号：为每个渠道分配独特的跟踪链接或注册代码，在启动前决定，因为事后无法添加。连续两届为零的渠道在下届活动中失去其权重。如果一个合作伙伴渠道服务多个不同的封闭社区（学校、专业团体），给每个社区自己的代码，而不是一个共享的合作伙伴代码：它跟踪哪个特定社区实际转化，并且对该社区而言，这读作专门为他们制作的邀请，而非通用折扣。
  • 超出人数的漏斗人口统计（自行设定，判断而非基准）：角色组合、地理位置，以及一个多数计划忽略的数字——注册是否让与会者付出门票价格之外的实际代价，例如下一个工作日的请假。只询问角色复选框的注册表单过滤成本低，但排除了不符合任何列出的标签的人；如果这个权衡是有意做出的，将节省的努力投入信息表达（谁受欢迎、典型与会者什么样），而不是让排除不被处理，并从首届开始加宽复选框列表，而不是在缺口可见后再修补。
  • 注册表单上的自我报告来源：“你从哪里听说我们”低估自有渠道，并重复计算注册者最后看到的内容。仅作为对跟踪链接的交叉检查，绝不能作为主要归因。
  • 覆盖与转化分离（自行设定的诊断）：注册页流量健康但转化低，指向价格或页面问题，而非渠道组合问题——路由到 
    samber/dev-event-organizer-skills@event-ticket-pricing
    或 
    samber/dev-event-organizer-skills@event-landing-page
    ，而不是购买更多覆盖。

Invocation examples

调用示例

  • "We're running a 400-person paid DevOps conference in October - build the marketing plan: channels, calendar and targets."
  • "Our free hackathon needs 500 attendees. Registrations open in three months. What should the campaign look like and how many signups do we need by when?"
  • "We're a month out and sitting at 28% of expected ticket sales. Is this a demand problem or did we under-market?"
  • "We have €2,000 for promotion and a volunteer team of four. Where should it go?"
Expected output:
  • The chosen spine, named with its reason.
  • The target, net of comps.
  • An audience-to-channel map with weights and the segment each channel is bought for.
  • A dated campaign calendar with every fixed date pinned onto the spine's checkpoints.
  • A budget posture with allocation.
  • Per-phase funnel targets.
  • A routing list naming which sibling executes each channel.
  • “我们在十月份举办一场400人的付费DevOps会议——制定营销计划：渠道、日历和目标。”
  • “我们的免费黑客马拉松需要500名与会者。注册三个月后开放。活动应该是什么样，我们需要在什么时候达到多少报名？”
  • “我们还有一个月，目前处于预期门票销售的28%。这是需求问题还是我们营销不足？”
  • “我们有2000欧元的推广预算和一个四人的志愿者团队。应该花在哪里？”
预期输出：
  • 选择的主线，并说明原因。
  • 扣除免费票后的目标。
  • 受众到渠道的映射，包含权重和每个渠道被购买所服务的细分。
  • 带日期的活动日历，每个固定日期固定到主线的检查点上。
  • 预算姿态及分配。
  • 每个阶段的漏斗目标。
  • 路由列表，说明哪个兄弟技能执行每个渠道。

References

参考

  • references/calendar-spines-and-phase-targets.md - both checkpoint ladders in full, a worked calendar for each spine, the net-of-comps calculation, and the per-phase target method.
  • references/channel-menu-and-budget-allocation.md - the channel taxonomy, campus-scale tactics, the owned/earned/paid framing, the four budget postures, and the percentage allocation table.
Channel executors (route each channel to the appropriate sibling):
  • samber/dev-event-organizer-skills@event-social-media
    - owns the platform mix, content calendar and amplification kits inside the social channel.
  • samber/dev-event-organizer-skills@event-landing-page
    - owns the registration funnel's on-page conversion; this plan drives traffic to it.
  • samber/dev-event-organizer-skills@event-attendee-email-sequences
    - writes the emails whose send moments this plan's calendar places.
  • samber/dev-event-organizer-skills@event-comms-channels
    - owns channel selection methodology and voice consistency; this plan consumes that choice rather than re-deriving it.
  • references/calendar-spines-and-phase-targets.md - 两条检查点阶梯的完整版、每个主线的计算日历、扣除免费票的计算以及每个阶段的目标方法。
  • references/channel-menu-and-budget-allocation.md - 渠道分类、校园规模策略、自有/赢得/付费框架、四种预算姿态和百分比分配表。
渠道执行者（将每个渠道路由到适当的兄弟技能）：
  • samber/dev-event-organizer-skills@event-social-media
    - 拥有社交渠道内的平台组合、内容日历和放大工具包。
  • samber/dev-event-organizer-skills@event-landing-page
    - 拥有注册漏斗的页面内转化；本计划将流量驱动到它。
  • samber/dev-event-organizer-skills@event-attendee-email-sequences
    - 编写本计划日历安排发送时机的邮件。
  • samber/dev-event-organizer-skills@event-comms-channels
    - 拥有渠道选择方法论和声音一致性；本计划消费该选择而非重新推导。