sales-push-notification について
sales-push-notificationは、モバイルとWebのプッシュ通知戦略を扱うスキルです。通知施策の計画、改善、測定に取り組むマーケティングチーム向けに、許可取得から分析まで複数のプラットフォームの指針を提供します。
主な機能
- 01プッシュ通知戦略の策定
- 02通知許可取得とメッセージ設計の改善
- 03セグメント、配信時刻、頻度上限の設定
- 04A/Bテストと効果測定の計画
- 05複数のプッシュプラットフォームに関する案内
活用シーン
- 01iOSのプッシュ許可を促す導線を設計
- 02カート放棄通知の内容と配信時刻を計画
- 03プッシュ基盤を比較して技術設定を計画
- 04低い開封率や高い配信停止率の原因を調査
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ sales-skills/ sales --skill sales-push-notificationインストール後、Claude Code で/sales-push-notificationを入力して読み込まれたか確認します。
同梱ファイルreferences/learnings.mdreferences/platform-guide.md
詳細
モバイルと Web のプッシュ通知
オプトインの最適化やメッセージの設計から、セグメンテーション、配信タイミング、配信頻度の上限設定、分析まで、プッシュ通知戦略を支援します。このスキルは特定のツールに依存しませんが、Braze、OneSignal、Airship、Firebase/FCM、Customer.io、Klaviyo、Iterable、MoEngage に関するプラットフォーム固有のガイダンスも含まれています。
ステップ 1 — 背景情報を集める
references/learnings.md が存在する場合は、蓄積された知見を得るため、最初に読みます。
ユーザーに次の質問をします。
-
どのようなサポートが必要ですか?
- A) 戦略 — プッシュ通知プログラムを一から計画する
- B) オプトインの最適化 — プッシュ通知の許可率を高める
- C) メッセージの設計 — コンテンツ、リッチプッシュ、アクションボタン、ディープリンク
- D) セグメンテーション — プッシュ通知の適切な対象ユーザーを選ぶ
- E) タイミングと頻度 — 配信タイミングと配信頻度を決める
- F) A/B テスト — プッシュ通知のバリエーションをテストする
- G) 分析 — プッシュ通知の効果を測定する
- H) ツールの選定 — プッシュ通知プラットフォームを選ぶ
- I) 技術的な設定 — SDK の統合、証明書、FCM キー
- J) その他 — 内容を記述する
-
対象とするプラットフォームは何ですか?
- A) iOS(iPhone/iPad)
- B) Android
- C) Web(ブラウザプッシュ)
- D) iOS + Android
- E) すべて(iOS + Android + Web)
-
使用中、または検討中のツールは何ですか?
- A) Braze
- B) OneSignal
- C) Airship(Urban Airship)
- D) Firebase Cloud Messaging(FCM)を直接使用
- E) Customer.io
- F) Klaviyo
- G) Iterable
- H) MoEngage
- I) まだ決めていない
- J) その他
ユーザーのリクエストから背景情報の大半がすでに分かる場合は、該当するステップに直接進んでください。 妥当な前提を明示したうえで、最善を尽くした回答を先に提示し、最後に重要度の高い確認事項だけを 1〜2 個尋ねてください。
ステップ 2 — 戦略とアプローチ
プッシュ通知が最も効果を発揮する場面
プッシュ通知は、次のような場合に最も価値があります。
- 時間的制約のあるアクション — フラッシュセール、期限切れ間近の特典、予約のリマインダー
- 取引に関する更新 — 注文の発送、配達の到着、支払いの受領
- 再エンゲージメント — 利用休止中のユーザー、放棄されたカート、まだ試していない機能
- ソーシャルなきっかけ — 誰かが「いいね!」、コメント、メッセージを送ったとき
- パーソナライズされたコンテンツ — おすすめ、スコアの更新、フォロー中のコンテンツ
次のようなプッシュ通知は価値が最も低く(配信停止につながる可能性も最も高く)なります。
- パーソナライズされていない一般的な販促通知
- 配信頻度が高すぎる通知(多くのアプリでは 1 日 1〜2 件を超える場合)
- メールやアプリ内通知で十分な内容
プッシュ通知のオプトイン戦略
iOS では、プッシュ通知に対するユーザーの明示的な許可が必要です。Android では自動的に有効になりますが、ユーザーが無効にできます。Web では許可を求めるプロンプトが必要です。
プッシュ通知の事前説明パターン(iOS では重要):
- 初回起動時に OS の許可プロンプトをすぐに表示しない
- まず、メリットを説明するカスタムのアプリ内メッセージを表示する(「注文の発送時に通知を受け取る」など)
- ユーザーがカスタムプロンプトで「有効にする」をタップした場合 → OS のプロンプトを表示する
- ユーザーが「今はしない」をタップした場合 → OS のプロンプトを表示せず、後でもう一度試す
- これにより、OS のプロンプトを早まって表示した結果、許可が恒久的に「拒否」される事態を避けられます
オプトイン率のベンチマーク:
- プッシュ通知の事前説明あり:50〜70% がオプトイン
- 事前説明なし(初回起動時に OS のプロンプトを表示):30〜40% がオプトイン
- Web プッシュ:5〜15% がオプトイン(ブラウザのプロンプトはネイティブより許可率が低い)
メッセージ設計の原則
- 短くまとめる — タイトルは 40〜50 文字、本文は 100〜120 文字を目安にします(iOS ではこれを超えると省略されます)
- 価値を先に伝える — ユーザーに何が得られるのかを伝えます。ユーザーに何をしてほしいかではありません。
- パーソナライズする — 名前、直近のアクション、商品への関心などを使います。一般的な内容は無視されます。
- 緊急性を演出する(控えめに) — 「あと 2 時間で終了」は効果的ですが、偽りの緊急性を作り出さないでください。
- リッチプッシュ — 画像、GIF、アクションボタンによってエンゲージメントが 20〜40% 高まります。
- ディープリンク — 必ず関連する画面にディープリンクし、アプリのホーム画面を開くだけにしないでください。
頻度とタイミング
頻度のガイドライン:
- トランザクション通知:上限なし — ユーザーはこうした通知を期待します(注文状況の更新など)。
- プロモーション通知:利用頻度の高いユーザーには週2~5回、ライトユーザーには週1~2回
- 上限:ほとんどのアプリカテゴリでは、1日1~2回を超えると通知を解除するユーザーが増えます
- 頻度制限を設定する:ほとんどのツールでは、ユーザーごとに1日または1週間あたりの上限を設定できます
タイミングの最適化:
- インテリジェントなタイミング設定(Braze、Iterable、OneSignal):機械学習に基づき、ユーザーごとに最適な送信時刻を設定します
- 手動で設定する場合の目安:一般消費者向けアプリでは、現地時間の午前10時~午後1時、午後6時~9時。深夜(午後10時~午前7時)は避けてください。
- 通知を控える時間帯:必ず通知を控える時間帯を尊重し、ユーザーを起こさないでください
ステップ3 — プラットフォーム固有のガイダンス
詳細なプラットフォーム比較、実装チェックリスト、主要指標については、references/platform-guide.md をお読みください。
プラットフォームガイドの詳細は不要になりました。ユーザー固有の状況に焦点を当ててください。
ステップ4 — 実行可能なガイダンス
ユーザー固有の質問に基づき、ステップ2の戦略フレームワークとリファレンスガイドのプラットフォーム詳細を活用して、的を絞った推奨事項を提示してください。
注意点
- iOS のプッシュ通知許可は取り消しできません — ユーザーが OS の許可ダイアログで拒否すると、再度確認することはできません(再度有効にするには、ユーザー自身が「設定」を開く必要があります)。そのため、プッシュ通知の導入案内が重要です。導入案内を表示せずに OS の許可ダイアログを表示してはいけません。
- Android 13 以降ではオプトインが必要です — Android 13(API 33)で、iOS と同様の実行時プッシュ通知許可が導入されました。Android ユーザー全員がデフォルトでプッシュ通知を有効にしていると想定しないでください。
- プッシュトークンには有効期限があります — ユーザーが数か月間アプリを開かないと、プッシュトークンが無効になることがあります。配信率を監視し、古いトークンを削除してください。90 日以上アプリを開いていないユーザーは、プッシュ通知を有効にしているユーザー数に含めないでください。
- Web プッシュのオプトイン率は低いです — ブラウザーのプッシュ通知許可ダイアログはユーザーに強く拒否される傾向があり、オプトイン率は5~15%です。Web プッシュを主要なチャネルとして頼りにしないでください。メールを補完する手段として使用してください。
- リッチプッシュには個別のアセットが必要です — iOS と Android ではリッチプッシュの扱いが異なります(画像サイズ、アスペクト比、アクションボタンの上限など)。公開前に、両方のプラットフォームでリッチプッシュをテストしてください。
- 自己改善:ここに記載されていないことがわかった場合は、今日の日付を付けて
references/learnings.mdに追記してください。
特定のプラットフォームスキルを推奨する前に
このスキルは、多数のプラットフォームにまたがる戦略領域を扱います。特定のプラットフォームスキル(## Related skills に記載されている /sales-{platform}。例:/sales-mailshake、/sales-klaviyo、/sales-apollo)をユーザーに案内する前に、まずそのプラットフォームスキルの実際の SKILL.md を読んでください。## Related skills の1行説明は候補を特定するには十分ですが、そのスキルを選択する判断や、適切に呼び出すプロンプトの作成には不十分です。
読み方:
~/.claude/skills/{skill-name}/SKILL.mdがローカルに存在する場合は、Readで読みます。sales-*スキルの場合は、このリポジトリからWebFetchで直接取得します:https://raw.githubusercontent.com/sales-skills/sales/main/skills/{skill-name}/SKILL.md— たとえば、sales-mailshakeの場合はhttps://raw.githubusercontent.com/sales-skills/sales/main/skills/sales-mailshake/SKILL.mdです。sales-*以外のスキル(サードパーティ製)の場合は、インストールされていれば~/.claude/skills/sales-do/references/skill-sources.mdで{org}/{repo}を調べ、そのリポジトリ内の同じskills/{skill-name}/SKILL.mdパスから取得します。
読んだ後は、 SKILL.md の具体的な内容(対象範囲、サブフロー、argument-hint の形式、「Do NOT use for...」という利用対象外の条件など)を根拠として推奨してください。生成する呼び出し内容は、プラットフォームスキルの argument-hint に合わせてください。プラットフォームスキルがユーザーの状況に合わない場合は、別のスキルに切り替えるか、適さないスキルを推奨するのではなく、この場で質問に直接対応してください。
関連スキル
/sales-iterable— Iterable プラットフォームのヘルプ(プッシュ通知の設定、Studio ジャーニー、Brand Affinity、STO)/sales-braze— Braze プラットフォームのヘルプ(プッシュ通知の設定、Canvas 連携、BrazeAI のタイミング)/sales-customerio— Customer.io プラットフォームのヘルプ(Journeys でのプッシュ通知)/sales-klaviyo— Klaviyo プラットフォームのヘルプ(Shopify の e コマース向けプッシュ通知)/sales-omnisend— Omnisend プラットフォームのヘルプ(e コマース向けウェブプッシュ+メール+SMS)/sales-sendpulse— SendPulse プラットフォームのヘルプ(ウェブプッシュ+メール+チャットボット+Automation 360)/sales-in-app-messaging— アプリ内メッセージとコンテンツカード(プッシュ通知の補完)/sales-email-marketing— メールマーケティング戦略(プッシュ通知とメールの配信頻度を調整)/sales-sms-marketing— SMS マーケティング戦略(プッシュ通知と SMS の配信頻度を調整)/sales-live-chat— ライブチャットとチャットボット(別のエンゲージメントチャネル)/sales-do— どのスキルを使えばよいかわからない場合は、ルーターがあらゆる営業目標に適したスキルを照合します。インストール:npx skills add sales-skills/sales --skill sales-do
例
例 1:プッシュ通知のオプトイン戦略を設計する
ユーザーの発言:「iOS のプッシュ通知オプトイン率がわずか 25% です。どうすれば改善できますか?」 スキルの動作:考えられる原因(事前説明なしで OS の許可プロンプトを早く表示しすぎていること)を診断します。プッシュ通知の事前説明フローを設計します。ユーザーが最初の重要なアクション(例:初回購入、初回保存)を完了した後にアプリ内メッセージを表示し、そのユーザーの行動に合わせた価値を説明して、「有効にする」をタップした場合にのみ OS の許可プロンプトを表示します。ベンチマークとして、事前説明を行うと 50~70% に達することを提示します。 結果:オプトイン率の 2 倍改善が見込まれる、プッシュ通知の事前説明実装計画
例 2:カート放棄プッシュ通知キャンペーンを作成する
ユーザーの発言:「e コマースアプリでカートを放棄したユーザーにプッシュ通知を送りたいです」 スキルの動作:3 段階のプッシュ通知シーケンスを設計します。1 時間後のプッシュ通知 1(「お忘れ物があります」+商品画像)、24 時間後のプッシュ通知 2(「まだご検討中ですか?商品が売り切れそうです」)、48 時間後のプッシュ通知 3(特典付き:「本日中に購入すると 10% オフ」)。カートへのディープリンク、配信頻度の上限、終了条件(購入時に配信対象から除外)も含めます。 結果:配信タイミング、コンテンツ、ディープリンクを含む、カート放棄者向けの自動プッシュ通知キャンペーン
例 3:プッシュ通知プラットフォームを選ぶ
ユーザーの発言:「シリーズ A のスタートアップで、MAU は 5 万です。プッシュ通知には OneSignal と Braze のどちらを使うべきですか?」 スキルの動作:OneSignal(無料プランがあり、シンプルで、プッシュ通知が主な用途に適している)と Braze(エンタープライズ向けで高価ですが、複数チャネルに対応する強力な機能を備えている)を比較します。MAU が 5 万の場合は、無料で設定がすばやく、プッシュ通知と基本的なメールに対応できる OneSignal の利用を推奨します。MAU が 50 万を超えた場合や、高度な複数チャネルのジャーニーが必要になった場合に Braze の再評価を提案します。 結果:規模の拡大に応じた移行パスを含む、明確な推奨案
トラブルシューティング
プッシュ通知の開封率が低い
症状:プッシュ通知を送信しているものの、開封率が 3% 未満 原因:メッセージにパーソナライズがない、配信タイミングが悪い、またはエンゲージメントの低いユーザーに送信している 解決策:1)最近のアクティビティでセグメント化し、過去 30 日以内にアクティブだったユーザーにのみ送信します。2)インテリジェントな配信タイミング/送信時間の最適化を有効にします。3)ユーザー名と関連性の高いコンテンツでパーソナライズします。4)リッチプッシュ(画像、アクションボタン)を使います。5)タイトルと本文を A/B テストします。6)配信頻度を見直し、1 日 1 回を超えている場合は減らします。
オプトアウト/無効化率が高い
症状:毎月 2% を超えるユーザーがプッシュ通知を無効にしている 原因:配信頻度が高すぎる、コンテンツに関連性がない、または配信頻度の上限が設定されていない 解決策:1)配信頻度の上限を設定します(プロモーションプッシュ通知は 1 日あたり最大 1~2 件)。2)興味に基づいてセグメント化し、全員に一斉送信しないようにします。3)ユーザーが通知の種類を選べるよう、設定センターを追加します。4)コンテンツの関連性を見直し、価値を届けているのか、それとも不要な通知を送っているだけなのかを確認します。5)14 日以上エンゲージメントのないユーザーへのプロモーションプッシュ通知の頻度を減らします。
iOSでプッシュ通知が届かない
症状:プッシュキャンペーンで送信数は表示されますが、iOSで配信されません。 原因:APNs証明書の期限切れ、無効なトークン、またはサンドボックス環境と本番環境の不一致です。 解決策:1) プッシュプラットフォームの設定でAPNs証明書の有効期限を確認します。2) 正しい環境(開発用はサンドボックス、App Store用は本番環境)が使われていることを確認します。3) Xcodeプロジェクトでプッシュ通知のエンタイトルメントが有効になっていることを確認します。4) 新しいトークンを生成するため、アプリを新規インストールしてテストします。5) AppleのAPNsステータスページで障害が発生していないか確認します。