シーズン終了

PokeTree

クリスマスに匿名の手紙を送り合い、手紙を開くたび図鑑も進む季節限定Webサービスです。

自分のツリーを共有して匿名の手紙を受け取り、手紙を開くたび図鑑も進むクリスマス限定Webサービスです。収集を再訪理由として提案し、画像アセット、共有UI、一部のGo CRUD APIルートを担当しました。

リンク

ツリーを共有し、匿名の手紙を受け取る体験

PokeTreeは、自分のクリスマスツリーのリンクを友人へ共有し、匿名の手紙を受け取る季節限定Webサービスです。受け取った手紙はクリスマスに開き、メッセージと一緒にキャラクターを集められます。

手紙を受け取る瞬間は楽しい一方、新着を確実に知らせる手段がなく、一度訪れたあとに戻る理由が弱いという課題がありました。短い期間だけ使うサービスのために、アプリのインストールを求めるのも現実的ではありません。

そこで通知機能そのものを作るのではなく、その目的を『もう一度訪れてもらうこと』と捉え直し、手紙を開く体験にキャラクター収集を組み込みました。

再訪につながる流れ

手紙を読む本来の行動に、収集の楽しさを重ねる

PokéTreeで初めてGoサーバーの実装を担当しました。画面の操作だけでなく、リクエストを受け取り、DB処理へ渡し、レスポンスを返すまでを実サービスのコードでつなぐ必要がありました。

サーバー全体と手紙の中心APIは別のメンバーが担当していました。初めてのサーバー作業だったため、新しい構造を作るより既存のルーティング、ハンドラー、DBアクセス、レスポンス形式を理解し、割り当てられたCRUDルートを同じ規則に合わせることが重要でした。

既存コードをたどってリクエストからレスポンスまでの責任を確認し、一部のGo CRUD APIルートを実装しました。フロントエンドの操作がどのエンドポイントを呼び、ハンドラーとDB処理を経てどのレスポンスで戻るかを一つの流れとして確認しました。

実際にシーズン運営されたサービスで、担当したGo CRUDルートを既存サーバーへ接続しました。

初めて扱うサーバーでも、リクエストからレスポンスまでを既存構造に沿って追うと、自分の実装範囲と前後の責任を具体的に理解できました。

匿名の手紙は開く瞬間には価値がありますが、Webでは新着を確実に知らせにくく、一度訪れた後に戻る理由が弱い状態でした。

短いクリスマス期間のためにアプリのインストールや新しい通知基盤を求めるのは重すぎました。また、別のミニゲームを追加すると、手紙を読むという中心行動から利用者を離してしまいます。

通知機能そのものではなく『もう一度確認する理由』を作ることに目的を置き、手紙を開くとランダムなキャラクターが図鑑へ加わる流れを提案しました。

通常80種類とクリスマス当日解放の1種類で図鑑を運用しました。ただし、収集機能単独の再訪効果は測定していません。

機能名より、利用者にもう一度してほしい行動を先に決めると、中心の流れの中でより軽い解決策を選べました。

GA4で確認した訪問者数は約1.5万人でした。通常80種類とクリスマス当日開放の1種類で、シーズン中のコレクションを運用しました。

機能を作る前に、利用者に戻ってきてほしいのか、共有してほしいのか、手紙を開いてほしいのかを具体的に決めるようになりました。また初めてGo CRUD APIルートを実装し、ボタン操作がHTTPリクエスト、ハンドラー、DBクエリ、レスポンスを経て画面更新へ戻るまでを追えるようになりました。

この数値は訪問者数であり、登録者・アクティブユーザー数ではありません。収集機能単独の効果も測定していません。