Amazon Pinpoint × グロースハック活用事例集

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Amazon Pinpoint ×
グロースハック活用事例集
石川勇太, ピクシブ株式会社コミック事業部 Palcyチームアーキテクト
平山知宏, ルームクリップ株式会社取締役 CTO
塚田朗弘, アマゾンウェブサービスジャパン株式会社スタートアップソリューションアーキテクト
AWS Dev Day Tokyo 2018

Topics
• ユーザーエンゲージメントをたかめる
• Palcy & Pinpoint
• Pushをもっと PDCA するための Pinpoint

ユーザーエンゲージメントを
たかめる

自己紹介
• Akihiro Tsukada @akitsukada
• Startup Senior Solutions Architect
• #startup #blockchain
#fintechsecurity #serverless
#mobile #megurodev
• Amazon Pinpoint かわいい！

こんな Pinpoint 情報も！
https://aws.amazon.com/jp/campaigns/manga/vol5-2/

グロースハック – Growth Hack
1. Sean Ellis 氏 (CEO of GrowthHackers) の生み出した言葉
2. データからKGI, KPIを定め、施策を打ち、振り返り、を繰り返す
3. 顧客価値の最大化（≒プロダクトの改善）と
事業の成長にフォーカスする

モバイルアプリが *アン* インストールされる7つの理由
1. ソーシャルログインの強要
2. プライバシーの懸念
3. ジャマな広告
4. ダメな UI/UX
5. フリーズ
6. 複雑なユーザ登録
7. うるさい通知
→ 価値ある内容の通知を、欲している人へ届けよう
https://www.prlog.org/12254771-top-7-reasons-why-mobile-users-uninstall-apps.html より引用
※ Appiterate 調べ

適切なエンゲージメントとそこに至る課題
1. タイミング: いつ
• どうやって適切なタイミングを知るのか
2. ターゲット: 誰に
• 対象をどう抽出するのか
3. 内容: 何をして（送って）
• メッセージをどう最適化するのか
4. 結果: どうだったか
• どう確認するのか
→ 自前で構築・運用するのは高コスト

これらの課題に
Amazon Pinpoint で
立ち向かう

Amazon Pinpoint Overview
可視化・分析各種イベント送信
○○クリック
セグメントプッシュ・個別プッシュイベントトラッキングと可視化
ディレクター,
マーケター
該当ユーザのみに
プッシュ通知送信
東京都の20代女性に
「限定イベント中！」
と送信
アプリ起動
△△購入
etc,etc…
グラフ表示
13%
100%
ファンネル分析
• ユーザ行動の解析と可視化
• ターゲティング通知配信
• プッシュ、Email、SMS、カスタム
• 配信数、開封率等の把握
AWSによる
ユーザーエンゲージメント
プラットフォーム

キャンペーンによるセグメントプッシュと分析
ユーザ
セグメント
マーケター、
ディレクターユーザ
セグメント
ユーザ
セグメント
①DeviceToken送信
②標準属性:自動送信、
カスタムユーザ属性:必要に応じて送信
カスタムイベント:必要に応じて送信
③送信対象セグメントまたは条件、
送信内容、送信タイミング等を指定
セグメントC（音楽ジャンル:ロックが好きで、
直近7日間アプリを起動しておらず、iOSアプリ
の最新バージョンを使っている人）に、
「{username}さん限定キャンペーン！」
とプッシュ通知で今すぐ送信。
ローカルタイムで21時以降のユーザは除く。
通知をタップしたらキャンペーンページに遷移。
④対象セグメントに指定された内容が
高速配信（100万件/分）される
※送信速度の調整も可能
⑤送信後の効果をダッシュボードで確認する

詳細なダッシュボード

モバイルプッシュの分析
1. Delivery metrics
1. Open rate
2. Delivery rate
3. Users messaged
2. Campaign session
heat map
3. Campaign metrics
1. Sent
2. Delivered
3. Directly opened

E メールの分析
1. Delivery metrics
1. Open rate
2. Bounce rate
3. Delivery rate
4. Users messaged
2. Campaign metrics
1. Sent
2. Delivered
3. Clicked
4. Opened

SMS の分析
1. Delivery metrics
1. Delivery rate
2. Users messaged
2. Campaign metrics
1. Sent
2. Delivered

イベントストリームによる高度な分析
Amazon
S3
BigData分析
Data
Amazon
EMR
ETL
AWS
Glue
Amazon
Athena
Amazon
Redshift
Amazon
EMR
(Hive, Presto..)
DATAACCESS
Query Engine
Amazon
QuickSight
VISUALIZE
BI, Dashboard
QUERY
Amazon ES
(Kibana)
リアルタイムダッシュボード
Amazon
Kinesis Data
Analytics
Amazon
Kinesis Data
Streams
Amazon
Kinesis Data
Firehose

送信速度をはじめとした細かい調整
• 一人のユーザが受け取る一日辺り
最大メッセージ数: 1 〜 100
• 一人のユーザが受け取る
キャンペーン辺り
最大メッセージ数: 1 〜 100
• 秒間最大メッセージ送信数:
0〜25,000
• キャンペーン辺り最長持続時間:0〜
• 配信除外時間
• 省略表示: 10,534,534 など大きな数字
を 10.53M と単位付きで簡素に

セグメントのインポート
インポートされた
セグメントに
プッシュ通知
Amazon
Pinpoint
Amazon
S3
Pinpointに
インポートAmazon
S3
Amazon
Athena
• リストさえ作れれば高速プッシュ通知基盤として利用可能
• 例えば AWS Mobile SDK を入れなくても Pinpoint から
通知を配信することはできる
Amazon
RDS
データベース等を使って
プッシュ配信したい集団を抽出し
CSV/JSONをS3に配置

動的なカスタムチャネル、セグメントフィルタ
（2018.11.02 現在パブリックベータ中）
カスタムチャネル
モバイルプッシュ
メール
SMS
ブラウザプッシュ
Facebook
メッセンジャー
etc...
セグメントフィルタ
…
送信対象
セグメント

Palcy & Pinpoint
20 2018.11.2
pixiv.inc
石川勇太

21
目次
• 自己紹介 & Palcy紹介
• Palcyでの通知と要件
• Pinpointを採用した理由
• Pinpointを採用してよかったこと
• リリース後に変化した要件と運用
• Reproを採用した理由
• PinpointとReproの併用した理由と結果

自己紹介
22
ピクシブ株式会社
コミック事業部エンジニア
石川勇太
2017年4月にピクシブのプレミアムチー
ムへ参加後、同年9月からPalcyの開発に
参加。
以降、AWSリソースの管理やサーバー
サイドアプリの開発を行っています。

23
作者と読者双方のアクションを通じ
てマンガ文化そのものを応援してい
くために、講談社とピクシブが共同
開発したマンガアプリ。
ユーザー登録数は10万人を超え、掲
載コミック数は300作品近くになり
、名作やSNSで話題のオリジナルマ
ンガも掲載しています。

エール
24
マンガを読んだり、実績を達成し
たときにもらえるポイント。
毎月ラインナップが変わり、種類
もアイマスクやマグカップなどが
増えています。

25
実績
マンガを読んだり、いいねしたり、
対象作品を読破したり、アプリを
通してマンガを応援してくれると、
イラストやアプリ内で使えるアイテ
ムが貰えます。

26
Palcyでの通知の要件
• マンガが読めるチケットが1日2回配布されるので、全ユーザーに通知し
てお知らせしたい
• スタートアップアプリのため、通知や分析に多くのコストを割けないた
め、なるべく低く抑えたい
• 通知を打ったことによるスパイクアクセスはなるべく避けたい
• 将来的にメールアドレス認証を予定しており、メールで通知もしたい
• 将来的に特定セグメントに対してユーザー毎にメッセージを変えて送信
したい

従量課金制であること
• 規模に応じてコストが変わるため、調整しやすく運用しやすい
メールも送れること
• Congnitoでメールアドレス認証する必要があるが、それを行えば
プッシュ通知と同じID(EndpointID)でメッセージを送ることができる
27
Pinpointを採用した理由

Pinpointの導入が容易だった
• アプリでは、SDKを入れて少しコードを書けば良いだけ
• AWS側では、Cognitoを使用しつつCognitoにPinpointの権限を
付与するだけ
• Palcyでは認証部分で既にCognitoを使用しているため、
簡単に導入できた
28

個別通知が比較的送りやすい
• サーバーから対象セグメントを作り、送信メッセージをエンドポイントのカス
タム属性に登録しておく
• 作成したセグメントとカスタム属性を使ったメッセージを使ってキャンペーン
を作成する
• 1件ずつ通知でも可能だが、その場合は開封率などが取れない
• 他サービスも候補にあったが、サーバーから情報が送れない、コストが見合わ
ない等で採用に至らなかった
29

30
Pinpoint採用してよかったこと
プッシュ通知の流量調整がミスなく運用できたこと
• 他サービスでもキャンペーン毎に流量調整が可能だがそれだと設定し忘
れることがある。PinpointはProject全体で設定できるので安心
ローカルタイムゾーンの時間で通知できる
• ユーザーのライフサイクルを阻害しない時間帯に送れるのがよい
• Palcyでは日本時間7時と19時に送っているが、海外にいる場合はその国
の7時と19時に通知することが可能

31
リリース後に変化した要件と運用
• 新作作品の通知やエール応募の当選を当選者にもっと強調して知らせたい
等、講談社の運用者側で自由に分析・通知したい要件が出てきた
• リッチな表示で通知をしたい、起動時に対象ユーザーに通知を表示したい
• ピクシブ側で都度依頼を受けて分析・運用する案もあるが、スピードが
だいぶ落ちてしまう懸念がある

32
Reproを採用した理由
• 講談社の運用者がReproに使い慣れていたため、教育コストが
ほぼなくなった
• アプリ内メッセージでリッチな通知を送れる

33
PinpointとReproの併用した理由
• メールでの通知要件が満たせないのでPinpointと併用している
• 使用できるイベント数はPinpointの方が多いため、とりあえず貯めて
おいてあとで分析がしやすい

34
PinpointとReproの併用した結果
• 月額費用で比較してみると、PinpointとReproでは数十倍の差がある
• スタートアップアプリのような場合、Pinponintの方が従量課金のため導
入しやすい
• ディレクターや運用者などのエンジニア以外が使う場合は、管理画面上
にプレビューがあったり、すでに分析されている方が導入しやすい
• 様々なデバイスに通知を送る場合は、Pinpointの方が１つのシステムで完
結する

Pushをもっと
PDCAするためのPinpoint
35

Copyright © RoomClip Inc. All Rights Reserved
RoomClipについて
「部屋って（みんな思ってる以上に）もっと遊べるよ！」
36

RoomClipについて
ガジェット：いろんなものあるよね、使い方次第で世界広がるよね。
コーディング：いろんな工夫できるよね、できたもの使うの楽しいよね。
Dockerfile：インフラきれい！納得感のあるコンテナ作るの気持ちいよね。
DDD：蒸留しまくってコアドメインどんどん育つのサイコーだよね。
こういう工夫毎日してるよね、それ絶対シェアしてるよね、誰かのシェア
に刺激受けてるよね！！それ部屋でもできっからやろうぜ！！
37

本日の内容
• RoomClipのPushの歴史の話
• こういうことやりたいんだよ！の話
• こういうことはやりたくねぇんだよ！の話
• Pinpointを褒める話
• 実際使ってみた話
• これからの話
38

RoomClipにおけるPushの歴史
• 最初の頃は、、、
• 用途：とにかくユーザーさん全員に告知がしたい
• 実装：単発で全Pushやりきる実装
• しばらく経って、、、
• 用途：特定のユーザー群に個別のメッセージを送りたい
• 実装：クエリでセグメント、メッセージテンプレート、開封計測
• 最近では、、、
• 用途：マーケティングツールとして使いたい
• 実装：クエリでセグメント、カスタムメッセージ、効果計測、高速PDCA
39

要求仕様
1. 自由なセグメントに、自由な文面のpushを
2. 規模を気にせず
3. 安く
4. 簡単に送れて
5. 効果計測できる
40

直面した問題点
1. 柔軟なセグメント
• できればDBから送信対象を細かくクエリしたい
2. 高速で安定した送信
• 100件でも100万件でも気にせずポーンと送りたい
3. マーケッターが使えるUI/UX
• クエリがかけて、メッセージパターンを作れる人が、それだけやれば送信できる状態
4. 低キャッシュコスト、低運用コスト
• VM、コンテナ、裏で台数を操作するようなことに気を払いたくない
41

• とにかく真正面から送信するパターン
42
multi proc
multi proc
multi proc
single proc
全送信対象リスト取得
分配
push
push
push
シンプルで使い勝手はいいが、基本は根性。CPU効率を考えマルチプロセスにするとすぐに複雑になる。リトライ、
エラーハンドリングなどは各インスタンス任せで不安定。送信時にDB接続するような処理を挟むとDBコネクト周
りで即破綻。

• push送信部分だけマネジメントサービス使って見るパターン
43
SNSによって送信部分は確実、高速なものに。大量にできるTopicsとDBと二重管理されるEndpoint。さらに、メッ
セージは柔軟ではなくなる。。。
Amazon
SQS
Amazon
SNS
php proc
送信対象リスト取得
クエリ/メッセージ登録
ブロックにしてキュー
サブスクライバ
topics生成
push

直面する問題大事な観点
• どこまでをマーケッターがやりたがるのか？
• どこまでをエンジニアがやりたがらないのか？
44

マーケッターがやりたがること
1. 実はクエリは苦ではない。いやむしろ書かせて。
• 逆に変なセグメント仕様やだ。ぜーんぶクエリがいい
2. 誰あてにどんなメッセージにするか、とかはテンプレートじゃなくても全部平文でもいいときがあるよ
• スプレ上でメッセージ作ったりするし、、、違和感ないかとかそこで確認してるし、、、
3. 計測グラフ、ダッシュボードも嬉しいけどCSV出して。スプレでどうせ見るし。
4. 送信前とかにちょっと本当に大丈夫か確認したい
45

エンジニアがやりたがらないこと
1. SDKいれんのヤダー、メンテと依存関係めんどー
• 計測とかのためだけにいれるならFirebaseすでに入ってるんだけど、、、
2. 各ノードが外部サービス使うような分散システムは避けたい
• 先方事情のエラーハンドリングとか条件とか、、、考えたくない
• JSON吐き出して終わりにしたい
3. フルマネジメントはいいんだけど、「なんでもできる！」系にしてほしくない。
• SDKも重くなるし、できるだけ単一の機能として使いたい
• 他と重複してどっち使うの？とかはマジで避けたい
46

こうしたくなってきた
• 送信先とメッセージのJSON用意する
• それを送信時間になったらさっと送る
これだけの動きをしてくれればいい。。。
47

Pinpoint
• どうやらSNSよりPushに特化してるっぽい
• JSON対応もしているっぽい
• その他いろいろできるっぽいしきめ細やかな設定もある
• あれ、でもFirebase Notificationもあるよね
• 何が違うの
48

比較していいなと思ったところ
49
• Pinpointのかゆいところに手が届く感じ
• 配信速度が明瞭。100万/分。そして調節できる
• Pushのせいで落ちた！みたいにならないようにできる
• JSON形式の宛先メッセージインポートできる
• S3においておけばさっと送ってくれるのね！
• データはKinesisでストリームされる
• 簡単にイベント取得できる
• 期間内繰り返し配信とかスケジューリングできる
• カスタム属性が上書きできる
• わりかしお手頃価格
• 1$/100万

ルームクリップが採用したPinpointの使い方
一旦最小構成で採用してみる
• SDKいれて、マーケターにAWSログインさせて直接Pinpointを使ってもらう、、、
みたいな大規模な利用は一旦先送りしました
• セグメントはクエリで記述し、デバイス管理も社内管理としました
• JSONまでは自社システムで生成し、S3へ格納するまで
• 送信処理をPinpointでとりあえず行う
50

最近のPinpoint
• 最小でPinpoint使ってみるパターン
51
JSONまではシングルプロセスで安全に運ぶ。出来上がったJSONをちょっと事前にみとく、みたいなこともできる。
送信タイミングはまぁどんなに多くても10分ずれる、とか程度で済むような調整もできる。
proc
送信対象リスト取得
クエリ/メッセージ登録
JSON生成
push
Amazon
S3
Amazon
Pinpoint
キャンペーン生成

やや気になること
• なんかドキュメントすくねぇ…
• みんなもっと使おうぜ！結構便利だし！
• ほんとに一部の機能しか使ってない件について
• もっとデキる子のはず
• 開封計測とか自社のシステムなんだけどほんとならPinpointに送りたい。でもSDKはやだ。
• APIレイヤでゴニョゴニョしたい
52

これから
• SDKいれて計測ツールからセグメント生成からデバイス管理までPinpointで！
という風になるかどうかは結構議論
• DynamoやRDBに直接Pinpointがつながるようになればコンソール画面でクエリ書いて終わり、、、みたいにしたいな
53

Thanks

Amazon Pinpoint × グロースハック活用事例集

More Related Content

What's hot

Similar to Amazon Pinpoint × グロースハック活用事例集

More from Amazon Web Services Japan

Amazon Pinpoint × グロースハック活用事例集