期間限定イベント設計の実務――目的、報酬、救済、終了処理を一枚の仕様へ落とす
期間限定イベントは、既存の遊びに期限、目標、報酬、特別な見せ方を重ね、プレイヤーへ「今、この遊びを選ぶ理由」を作る施策である。
ただし、期限を付ければイベントになるわけではない。目的が曖昧なまま報酬だけを増やすと、短期的な参加率は上がっても、経済インフレや義務感、終了後の反動を残す。設計時には「誰に、どの行動を、どの程度楽しんでもらい、その後どうなってほしいか」を先に決める必要がある。
本稿は、運営カレンダー全体を扱う「ライブ運営の実務――リリース後90日から継続運営まで」より粒度を下げ、 1つのイベントを仕様へ落とす方法 に焦点を絞る。ログインスタンプにも触れるが、毎日のログイン習慣そのものは「ゲームのログインボーナスで継続率を下支えするコツ」へ譲り、イベント固有の目標、進行、救済、終了処理を中心に扱う。
1. 最初に「イベントの成功」を一文で定義する
イベント企画書の冒頭には、次の形式で目的を書く。
対象プレイヤーに、期間中は○○を体験してもらい、終了後に△△の状態へ移ってもらう。
たとえば「休眠プレイヤーに復帰してもらう」だけでは不十分である。「復帰プレイヤーに協力戦を3回体験してもらい、終了後もギルド活動へ参加できる状態にする」まで書けば、必要な導線と報酬が見えてくる。
目的は原則として一つに絞る。参加率、売上、新機能の学習、コミュニティ活性化をすべて同じ優先度で追うと、イベントの要求が膨らむからである。副次目標を置く場合も、主目標と競合したときにどちらを優先するか決めておく。
Google Playのプロモーション用コンテンツでは、期間限定イベント、オファー、大型アップデートを別種の情報として扱い、開始・終了日時、対象地域、対象ユーザー、説明、アプリ内への導線を設定する。イベントはゲーム内だけで完結せず、ストア、告知、通知、復帰導線まで一つの体験として設計する必要がある。[1]
企画開始時に固定する5項目
| 項目 | 記載例 |
|---|---|
| 対象 | メインストーリー第2章を終えた既存プレイヤー |
| 変えてほしい行動 | 協力戦を初めて遊ぶ |
| 提供する体験 | 役割分担しながら巨大な敵を攻略する |
| 主指標 | 対象者の協力戦初回完了率 |
| ガードレール指標 | 通常クエスト利用率、途中離脱率、問い合わせ件数 |
ガードレール指標とは、主指標を伸ばす過程で壊してはいけない指標である。売上が伸びても、通常コンテンツが遊ばれなくなり、問い合わせや翌週離脱が増えているなら、成功とは言いにくい。
2. イベントの主要な類型と狙いの違い
イベント形式は、作りやすさではなく、起こしたい行動から選ぶ。
| 類型 | 主に狙う効果 | 向いている状況 | 主な設計リスク |
|---|---|---|---|
| ログインスタンプ型 | 低負荷な再訪、イベント認知 | 復帰施策、大型企画への入口 | 受け取るだけで本編を遊ばない |
| ポイント交換型 | 周回、遊び方の選択、報酬選択 | 複数ステージを横断させたい場合 | 必要周回数が見えず作業化する |
| 協力・レイド型 | 共同行動、役割分担、コミュニティ形成 | ギルドやマルチプレイを活性化したい場合 | 人口不足、ただ乗り、時間帯格差 |
| ランキング型 | 習熟、競争、反復プレイ | スコア技術を競わせたい場合 | 上位独占、不正、過度な拘束 |
| ガチャ・排出連動型 | 新規キャラクターの獲得と試用、売上 | 商品とイベント体験を連動させたい場合 | 所持の有無で参加価値が分断される |
| コラボレーション型 | 新規獲得、復帰、話題化 | 外部IPから入口を作りたい場合 | 権利監修、再開催制約、固有名詞の説明不足 |
| 高難度チャレンジ型 | 熟練者の目標、編成研究 | 上位層に腕試しを提供したい場合 | 報酬差が大きいと未達者が損失を感じる |
| ストーリー解放型 | キャラクター理解、物語への再接続 | 新章や新キャラクターを紹介したい場合 | 周回要求が物語のテンポを壊す |
一つのイベントへ複数形式を組み合わせてもよい。ただし、主動詞は一つにする。「集める」「協力する」「競う」「物語を見る」がすべて必須になると、プレイヤーは何を楽しむ企画なのか理解しにくい。
ログインスタンプは、イベント本体ではなく入口として扱うと整理しやすい。初日に参加用アイテムを渡し、次に遊ぶ場所を明示する程度に留めれば、単なる受取画面ではなくイベントへの導線になる。
類型ごとに確認すべき固有仕様
ランキング型では、同点時の順位、集計締切、スコア訂正、不正者除外、報酬確定時刻を先に決める。ランキング基盤には、期間ごとに内容をリセットしつつ過去の結果を別バージョンとして保持する仕組みもある。[2] 終了後に順位を再計算する可能性があるなら、「終了」と「報酬確定」を同時刻にしてはならない。
協力・レイド型では、参加人口が予想より少なかった場合の成立条件を決める。敵HPの段階調整、少人数用難易度、NPC補充、個人目標への切り替えなど、失敗時の逃げ道が必要である。
コラボレーション型では、開催終了後も獲得アイテムを表示・使用できるか、音声や楽曲を再生できるか、復刻告知へ素材を再利用できるかを権利条件と照合する。期間終了後の仕様まで監修対象に含める必要がある。
3. 一つのイベントを6要素へ分解する
イベントは次の6要素へ分けると、仕様の抜けを見つけやすい。
3-1. テーマ――なぜ今、この行動をするのか
テーマは、装飾ではなくルールへ意味を与える役割を持つ。
「敵を100体倒す」だけでは通常任務との差が弱い。「各地に散った調査対象を追跡し、地域ごとの敵から証拠を集める」とすれば、複数ステージを巡る理由を作れる。ただし、表現を変えただけで同じ敵を過剰に周回させるなら、体験は変わらない。
テーマを決める際は、次の三つをそろえる。
- イベント中に何が起きているのか
- プレイヤーはどの立場で参加するのか
- なぜ通常時とは異なるルールや報酬が存在するのか
3-2. 達成目標――開始、完走、挑戦を分ける
一つの巨大なゴールだけを置かず、目標を三層に分ける。
| 層 | 役割 | 例 |
|---|---|---|
| 参加目標 | イベントの遊び方を理解させる | 専用ステージを1回完了 |
| 完走目標 | 主報酬まで到達させる | 累計ポイントで限定衣装を獲得 |
| 挑戦目標 | 余力のある層へ追加目標を渡す | 高難度条件、追加称号、上位スコア |
完走目標は、イベントの中心的な体験を一通り味わえば届く位置に置く。挑戦目標は高くてもよいが、未達によって基礎的な成長資源を大きく失わせない方がよい。
ゲームへの動機を説明する研究では、能力を発揮できる感覚、自分で選んでいる感覚、他者とつながる感覚が、ゲームへの関与と関連すると整理されている。[3] そのため、進捗量だけでなく、「上達が見える」「攻略方法を選べる」「協力の成果が見える」目標を組み込む方が、イベントを報酬回収作業にしにくい。
3-3. 報酬構造――何を、どの順番で渡すか
報酬は総量だけでなく、配置によって体験が変わる。
- 序盤には参加費や編成負担を軽くする消耗品を置く
- 中盤には完走を予告する目立つ報酬を置く
- 主報酬は一般的なプレイ量で届く位置へ置く
- 終盤は称号、外見、追加収集品などの挑戦報酬を中心にする
- 交換所では、最低限のおすすめと自由選択枠を分ける
報酬の受取操作も仕様の一部である。達成しても別画面で受け取らなければ失効する設計は、プレイではなくUI操作の見落としを罰する。重要報酬は自動付与するか、終了後に受取猶予を設ける方が安全である。
3-4. 進行状況の可視化――次の一手を一画面で示す
イベントトップ画面では、最低限次の情報を同時に確認できるようにする。
- 開催終了までの時間
- 現在の進捗と完走条件
- 次の報酬
- 今すぐ遊ぶべきコンテンツへのボタン
- 交換所の終了時刻
- 参加条件を満たしていない場合の解放方法
ポイントイベントなら、「現在3,200点」だけでは足りない。「主報酬まであと800点」「通常難易度なら約4回」が分かれば、残り時間との比較ができる。ただし、回数表示は編成や倍率で変わるため、前提条件を明示する。
3-5. 救済――遅れを消すのではなく、追いつき方を用意する
救済は、出遅れたプレイヤーへ無条件で全報酬を渡すことではない。残り時間で現実的な計画を立てられるようにすることである。
代表的な方法には次がある。
- 後半にポイント効率の高いステージを開放する
- 未消化回数を一定量まで翌日へ持ち越せるようにする
- ストーリー閲覧と報酬獲得を分離する
- 初回報酬を厚くし、短時間でも主要部分を体験できるようにする
- 協力戦の必要人数や全体目標を参加人口に応じて調整する
- 終了後に交換だけ可能な猶予期間を設ける
救済の強さは事前に数式で確認できる。必要ポイントを P、通常の1日獲得量を E、残り日数を R とすると、出遅れ時の必要倍率は P ÷ (E × R) で概算できる。残り2日で通常の5倍を要求するなら、画面上に救済ボタンがあっても実質的には追いつけない。
3-6. 終了状態――終わった瞬間に何が残るか
イベント仕様には開始条件だけでなく、終了後の状態を書く。
- 専用ステージへ入れるか
- 進行中のバトルを完了できるか
- ポイントを追加獲得できるか
- 交換所だけ残るか
- 未受取報酬をどう扱うか
- イベント通貨を削除、変換、持越しのどれにするか
- ランキング結果をいつ確定するか
- ストーリーを回想機能へ残すか
終了処理を後から決めると、告知、サーバー実装、補填方針が同時に崩れる。
4. 達成感を残しながら報酬インフレを抑える
報酬を前回より豪華にし続ける方法は、短期的には分かりやすい。しかし、次回も同量以上を期待され、通常コンテンツの価値まで低下する。
報酬設計では、まずイベントから経済へ流入する総量を計算する。
期待流入量 ＝ 対象人数 × 参加率の想定 × 1人あたり平均獲得量
さらに、通貨、強化素材、装備、キャラクター成長素材を別々に集計する。同じ「10個」でも、日常的に消費される素材と、長期間価値を持つ希少素材では経済への影響が違う。
消費される報酬と、アイデンティティに紐づく報酬
| 報酬 | 強み | 注意点 |
|---|---|---|
| 通貨、回復薬、強化素材 | 幅広い層に価値が伝わる | 配布増加が常態化しやすい |
| イベント用便利アイテム | 開催中の遊びを滑らかにする | 終了後の用途が残りにくい |
| 衣装、称号、プロフィール装飾 | 経済数値を押し上げず、参加記録になる | 好みに合わない層には価値が低い |
| 限定演出、スタンプ | 協力・交流体験と結びつけやすい | 使用場所が少ないと存在を忘れられる |
| 記念家具、図鑑項目 | 収集と振り返りに向く | 保管上限や再入手機会の整理が必要 |
主報酬を成長資源だけにすると、参加理由が「遅れないため」になりやすい。逆に、すべてを外見報酬にすると、興味のないプレイヤーには参加価値がなくなる。実務上は、序盤に実用品、完走地点に象徴的な報酬、挑戦地点に追加の装飾を置く構成が扱いやすい。
ガチャ連動イベントでは、有料ガチャの対象アイテムと提供割合を分かりやすく表示する必要がある。CESAのガイドラインは、有料ガチャで取得できる全アイテムと提供割合の表示を原則としている。[4] Appleも、購入を伴うランダム型アイテムについて、購入前の確率開示を求めている。[5]
法令やプラットフォーム規則への適合だけでなく、イベント参加条件も分離して考えるべきである。新キャラクターを持っていれば効率が上がる設計は可能だが、未所持では物語や主報酬へ到達できない設計にすると、イベントが商品の所持確認になってしまう。体験用レンタル、低倍率の無料ルート、共通編成ステージなどを用意し、購入と参加の境界を明示する必要がある。
5. 「積みイベント」を時間と画面の両方から判定する
複数イベントの問題は、開催本数だけでは測れない。同時に3本あっても、通常プレイ1回で進捗が共有されるなら負担は小さい場合がある。逆に1本でも、毎日異なる時間帯へログインし、複数画面で受取操作を求めるなら重い。
イベント負荷は、少なくとも次の四つへ分けて見る。
| 負荷 | 確認内容 |
|---|---|
| 時間負荷 | 主報酬までに追加で必要なプレイ時間 |
| 注意負荷 | 覚える通貨、締切、交換所、ルールの数 |
| 操作負荷 | 受取、編成変更、画面移動の回数 |
| 機会負荷 | イベント参加によって諦める通常コンテンツ |
ペーシングの判断軸
- 開催中イベントの主報酬をすべて狙った場合、想定プレイ時間へ収まるか
- 同じ日に複数の締切や更新時刻が存在しないか
- イベントごとに異なる専用通貨を増やしていないか
- 通常プレイが複数イベントの進捗へ自然に反映されるか
- 新しいルールを説明するイベントが同時に複数走っていないか
- ホーム画面の告知、赤い通知印、ポップアップが競合していないか
- 一つ見送っても、恒常的な成長から大きく脱落しないか
「積みイベント」の兆候は、参加率の低下だけではない。各イベントへ少しずつ触れて完走しない、交換忘れが増える、告知を閉じるまでの操作が増える、問い合わせで締切の混同が起きる、といった形でも現れる。
並行開催する場合は、入口をまとめるとよい。イベントポータルで「今週の主役」を一つ示し、他の企画を補助枠へ置く。すべてを同じ強さで催促すると、優先順位をプレイヤーへ丸投げすることになる。
6. FOMOを期限の説明に留め、参加強制へ変えない
期間限定イベントには、取り逃し不安、いわゆるFOMOが構造的に含まれる。期限そのものを消す必要はない。問題は、期限を理解のために使うか、判断を急がせるために使うかである。
許容しやすい催促
- 実際の終了日時を常に同じ形式で表示する
- 終了前に、残り時間と未交換品を知らせる
- 通知を拒否・調整できる
- 主報酬までの残量を具体的に示す
- 復刻予定が決まっている場合は開示する
- 参加しない選択でも恒常成長が破綻しない
強制感が強くなる境界
- 期限が切れるたびに同じオファーが再出現する
- 「最後の機会」と表示しながら再販売予定を隠す
- 休んだ日の進捗を完全に失わせる
- 重要な終了条件を小さな注意書きへ隠す
- 通知を閉じても別画面で繰り返し表示する
- 参加しないと対戦や協力へ必要な性能を長期間失う
- 報酬受取だけを開催期間より早く締め切る
FTCは、実際には限定されていないオファーへカウントダウンを表示したり、期限後にタイマーをリセットしたりする表現を、消費者を急がせるダークパターンの例として挙げている。[6] ゲーム内でも、カウントダウンは事実を伝える表示でなければならない。
実務で迷ったときは、次の問いを使う。
この表示を見たプレイヤーは、内容を理解して参加を選べるか。それとも、損失への不安だけで今すぐ操作させられるか。
後者へ偏るほど、短期指標と長期的な信頼の交換になりやすい。
7. 開始から終了までを状態遷移として設計する
イベントを「開催中」と「終了」の二状態だけで作ると、告知、集計、交換、障害対応が衝突する。最低でも次の状態へ分ける。
- 予告期間：ルール、参加条件、開始日時を知らせる
- 開催期間：進行とポイント獲得を許可する
- 獲得終了：新規ポイントの獲得を止める
- 集計期間：ランキング、不正、未反映データを確認する
- 交換猶予：保有ポイントの交換だけ許可する
- 確定・配布：順位報酬や未受取報酬を処理する
- アーカイブ：回想、履歴、次回引継ぎ情報を残す
日時はタイムゾーンを含めて管理し、クライアント時刻だけで判定しない。終了直前に開始したバトルを有効とするか、終了時刻までに結果送信が必要かも明記する。
開始前の運用チェック
- 想定同時接続数とAPI呼出数を見積もったか
- 開始直後、日次更新、終了直前の負荷試験を行ったか
- 報酬付与を再試行しても二重配布にならないか
- ランキングの同点規則と不正検知を確認したか
- 地域別の開始日時、夏時間、ローカライズを確認したか
- ストア、公式サイト、ゲーム内告知の日時が一致しているか
- 開始停止、倍率変更、入口非表示をサーバー側で実行できるか
- 障害時の第一報、延長、補填の責任者を決めたか
定時処理は手作業へ依存させず、開始、価格変更、配布、終了をスケジュール可能にする。PlayFabのScheduled Tasksも、イベント用設定の更新、仮想通貨の付与、時間帯による価格変更などを自動化の例として挙げている。[7]
終了時のアイテム処理
イベント通貨の扱いは、次回持越し、自動変換、猶予期間後に削除のいずれかを選び、獲得前から告知する。黙って削除してはならない。
自動変換する場合は、変換レート、端数処理、保有上限を決める。持越す場合は、次回の交換価格と初日進捗を壊さないか確認する。削除する場合は、交換所の残り時間と未交換量を目立つ場所へ表示する。
購入を伴う通貨は、イベント専用通貨と同じ扱いにしてはならない。Appleのガイドラインでは、アプリ内課金で購入したクレジットやゲーム内通貨を失効させないことが求められている。[5] 対象地域の法令、業界ガイドライン、各ストア規則も個別に確認する必要がある。
インベントリ処理には、追加、減算、削除、購入、移動をまとめて実行し、途中失敗時に全体を戻す仕組みや、再試行による二重処理を防ぐ識別子が利用できる。[8] 実装方式にかかわらず、報酬配布には取引履歴、再実行条件、重複防止が必要である。
途中終了や延長に備える
重大な不具合でイベントを止める場合は、少なくとも次を告知する。
- 何を停止したか
- 既に得た進捗やアイテムは保持されるか
- 再開または終了判断をいつ案内するか
- ランキングや購入へどのように影響するか
- 補填対象をどの基準で決めるか
ランキング型を単純延長すると、延長時間に参加できる人だけが有利になる。全員へ同じ時間を追加したつもりでも、公平性は回復しない場合がある。問題発生前の結果で確定する、無効化して再開催する、順位報酬を段階報酬へ置き換えるなど、形式ごとの代替案を事前に用意しておく。
8. 振り返りは参加率、成果、反動を分けて読む
イベント終了後は、売上や参加者数だけで成功を判断しない。イベント前、開催中、終了後の三期間をつなげて見る。
8-1. 基本ファネル
ここでいうファネルとは、対象者が告知を見て、開始し、完了し、翌週利用へ進むまでの各段階で、どこで人数が減ったかを見るための段階表である。
次の段階ごとに人数と離脱率を測る。
- イベント対象になった
- 告知またはイベント画面を見た
- 最初のプレイを開始した
- 最初のプレイを完了した
- 主報酬へ到達した
- 挑戦目標へ進んだ
- 終了翌週もゲームを利用した
参加率の分母は、全登録者ではなく「期間中に参加条件を満たし、イベントへ到達可能だったアクティブプレイヤー」とする。
参加率 ＝ イベントを開始した人数 ÷ 参加可能なアクティブ人数
同様に、完走率の分母は参加者、交換率の分母は交換可能な通貨を得た人とする。分母が曖昧な指標は、改善箇所も曖昧になる。
分析基盤では、画面閲覧、開始、完了、報酬受取、購入などを個別イベントとして記録し、対象者を属性や行動で分ける。Google Analytics for Firebaseも、カスタムイベントの記録、ユーザー群の定義、イベント発生人数や収益のレポートを提供している。[9]
8-2. 目的別に見る指標
| 目的 | 主指標 | 併せて見る指標 |
|---|---|---|
| 新規獲得 | イベント経由の新規開始数 | 初回完了率、翌日・翌週継続率 |
| 復帰 | 休眠者の復帰数 | 復帰後の本編進行、翌週継続率 |
| 新機能学習 | 初回完了率 | 再挑戦率、失敗地点、説明画面離脱 |
| 協力活性化 | 協力戦参加者数 | 募集成立率、待ち時間、継続参加率 |
| 収益 | 対象商品の購入率、純増売上 | 無課金・微課金・中課金・重課金ユーザー別の変化、返金、翌週継続率 |
| 競争 | 有効スコア提出者数 | 上位集中度、再挑戦率、不正検知数 |
| 消費促進 | イベント通貨の消費量 | 未交換残高、通常経済への流入量 |
売上は開催中の総額だけでなく、通常商品の買い控えや前後週からの需要移動も確認する。翌週継続率も、参加者が高関与層だったため高く見えている可能性がある。新規、復帰、既存、進行度、過去の課金状態などで分け、可能なら非参加者や過去の同種イベントと比較する。
A/Bテストを使う場合は、報酬量、必要周回数、告知頻度などを一度に変えない。PlayFab Experimentsは、対象セグメントを複数のバリエーションへ割り当て、エンゲージメント、収益、継続などの結果を比較する仕組みを提供している。[10] ただし、同じ商品へ異なる確率表示を行うなど、公平性や法令上の問題を生む条件は実験対象にしてはならない。
8-3. 数字とプレイヤーの言葉を対応させる
定量データだけでは、離脱理由を断定できない。
たとえば中盤離脱が多い場合も、原因には次の違いがある。
- 必要周回数が多い
- 次の報酬が見えない
- 難易度が急に上がる
- 編成変更が面倒である
- 通常コンテンツとのスタミナ競合がある
- 欲しい交換品を既に取り終えた
行動ログ、問い合わせ、アンケート、公式コミュニティの反応を照合し、「観測した事実」と「原因の仮説」を分けて記録する。
振り返り資料は、次の形式にすると次回へつなげやすい。
| 項目 | 記録内容 |
|---|---|
| 狙い | 変えたかった行動 |
| 結果 | 主指標とガードレール指標 |
| 想定との差 | どの層、どの段階で差が出たか |
| 原因仮説 | ログと定性情報から考えられる理由 |
| 次回変更 | 変更する変数を一つずつ記載 |
| 維持する点 | 数字と反応の両方が良かった部分 |
| 未検証 | 現時点では判断できない事項 |
9. 企画書へそのまま使える最終チェック
目的
- 対象プレイヤーが明確か
- 変えたい行動を一文で説明できるか
- 主指標とガードレール指標を決めたか
体験
- イベント中に何をするのか一画面で理解できるか
- 参加、完走、挑戦の目標を分けたか
- 通常コンテンツとの差が報酬以外にもあるか
- 主報酬までの残量と必要行動が見えるか
報酬と救済
- 経済への総流入量を試算したか
- 実用品とアイデンティティに紐づく報酬を使い分けたか
- 途中参加でも主な体験へ到達できるか
- 未受取報酬と未交換通貨の処理を決めたか
強制感
- 期限と条件を正確に表示しているか
- 参加しない選択で恒常成長が破綻しないか
- 通知やポップアップを拒否できるか
- 復刻や再販売について誤解を招く表現がないか
運用
- 開始、終了、集計、交換期限を別々に定義したか
- 負荷、不正、二重配布を検証したか
- 停止、延長、再開の判断者を決めたか
- ストア、公式告知、ゲーム内表示の日時が一致しているか
- 終了後に残るアイテム、物語、履歴を定義したか
計測
- 対象、閲覧、開始、完了、受取のログがあるか
- 指標の分母を定義したか
- 新規、復帰、既存、進行度、課金状態で分けて見られるか
- 開催翌週の継続と通常コンテンツへの反動を確認できるか
おわりに
良い期間限定イベントは、プレイヤーの予定を奪うのではなく、限られた期間に遊び方の焦点を作る。
企画時には、報酬表から書き始めない方がよい。対象、変えてほしい行動、中心となる体験、完走条件、救済、終了状態を先に一枚へまとめる。その後で報酬量、開催期間、告知、計測を当てはめれば、目的と仕様のずれを早い段階で発見できる。
イベントの価値は、開催中の数字だけでは決まらない。終了後に「参加してよかった」と感じられ、次の通常プレイへ自然に戻れることまで含めて、一つのイベント設計である。
References
1. プロモーション用コンテンツを作成する - Google Playにおけるイベントの開始・終了日時、対象ユーザー、予告、ディープリンク、提出手順を説明する公式資料。
2. PlayFab Leaderboards overview - ランキングのリセット方針、バージョン管理、同点処理などを説明するMicrosoftの公式資料。
3. A Motivational Model of Video Game Engagement - 自律性、有能感、関係性の充足とゲームへの関与を整理した研究論文。
4. ネットワークゲームにおけるランダム型アイテム提供方式運営ガイドライン - 有料ガチャの対象アイテムと提供割合の表示原則を示すCESAの公式資料。
5. App Review Guidelines - ランダム型アイテムの確率開示や、購入したゲーム内通貨の失効禁止などを定めるAppleの公式ガイドライン。
6. Bringing Dark Patterns to Light - 偽の期限、リセットされるカウントダウンなど、消費者の判断を急がせる表示を整理したFTCの報告書。
7. Scheduled tasks - イベント設定の更新、仮想通貨の付与、価格変更などの定時処理を説明するPlayFabの公式資料。
8. Items and Inventory Overview - インベントリの追加、減算、削除、原子的な一括処理、再試行時の重複防止を説明するPlayFabの公式資料。
9. Google Analytics for Firebase - カスタムイベント、ユーザー群、利用状況、収益などの計測機能を説明するGoogleの公式資料。
10. Experiments - プレイヤー群を複数条件へ割り当て、エンゲージメント、収益、継続などを比較するPlayFabの公式資料。
この文書は、Perplexity、Claude、OpenAI Codex の3つのAIの支援を受けて著述されたものです。引用画像を除き、MIT License にて提供されています。