【Firebase】Import segmentsの紹介とAudiencesとの比較
はじめに
Firebase Summit2020でFirebaseの新機能として
紹介された中で個人的に一番興味があったImport segmentsについて書いてみます
内容は以下2点になります
・Import segmentsについて簡単な紹介
・AudiencesとImport segementsの比較
Audiencesについてこの投稿で触れるので知らない方は以下記事をみていただけると幸いです!
Event, UserPropertiesを送っておくと戦略的に幅が広がる話
Import segementsについて
FirebaseProjectと連携してるBigQueryから
チームが定義したセグメントデータを利用できます。
このセグメントデータは
Cloud Messaging、RemoteConfigなどのFirebaseが提供する機能で使用できます。
これによりセグメントを対象に
通知であったりRemoteconfigの値を切り替えるなどの実装が可能になります。
Import segmentの設定
Console上よりインポートしたセグメントを有効にすると
連携してるBigQueryに自動で以下データセットとデータセット内に含まれるテーブルが作成されます。
データセット名:firebase_imported_segments
データセットに含まれるtable名: SegmentMetadata, SegmentMemberships
SegmentMetadata
schema
[
{
"name": "segment_label",
"type": "STRING"
},
{
"name": "display_name",
"type": "STRING"
}
]
segmentのマスターデータが入るテーブルになります。
segment_label | display_name |
---|---|
test_group | test_import_segment |
test_group_2 | test_import_segment_2 |
display_nameに指定した文字列は
Console上よりインポートしたセグメントを選ぶ際に表示される文字列になります。
segment_labelはSegmentMembershipsに含まれるsegment_labelsの値に紐づくユーザを集計するためのkeyかなと。
SegmentMemberships
schema
[
{
"name": "instance_id",
"type": "STRING"
},
{
"name": "segment_labels",
"type": "STRING",
"mode": "REPEATED"
},
{
"name": "update_time",
"type": "TIMESTAMP"
}
]
ユーザ情報(このテーブルではinstance_id)とユーザが属するsegementが格納されるテーブルになります。
ユーザは複数のsegmentに属する可能性があるため
segment_labelsは配列で持てるようになってると思われます。
SegmentMembershipsにデータを詰めていく作業が必要になり
これがImport segmentを使用する際に一番コストがかかりそうなところかな?と思ってます。
test_groupに属するユーザ(instance_id)
test_group_2に属するユーザ(instance_id)は以下テーブルのように表現できます。
SegmentMetadata, SegmentMembershipsにデータが入った状態であれば
Cloud Messagingなどで配信対象に作成したsegmentを指定することが可能です。
(↑時間差があるみたいです。
Audiencesとの違いは?
条件を満たすユーザのグループを対象に通知であったりRemoteconfigの値を切り替えるなどの実装が可能
条件を満たすユーザのグループを対象に通知であったりRemoteconfigの値を切り替えるなどの実装が可能
これは既存機能のAudiencesでも可能ですがImport segmentsと比較する上で二つの項目それぞれどちらが優位性が高いか?についてまとめた表が以下です。
比較内容 | Audiences | Import segements |
---|---|---|
作りやすさ | win | lose |
耐久力 | lose | win |
作りやすさ
Import segmentsではSegmentMembershipsに
スキーマに合う形式でデータを詰める作業を開発者側で行う必要があります。
AudiencesではConsoleでぽちぽち設定で作りたいグループが作成できるので作りやすさはAudiencesの方が優位性が高いと思ってます。
耐久力
Biz側からくる要望に耐えられるかを意味します。
Audiencesでは作りたいグループが作れないがImport segmentsでは作成可能となるケースがあるので耐久力はImport segmentsの方が優位性が高いと思ってます。
Audiencesの場合アプリからEvent,Eventに紐づくParameter,UserPropertyを送るように設定することでAnalyticsのデータがBigQueryの_eventテーブルに格納されここのデータを元にグループを作成することが可能です。
裏を返すと、_eventにデータがないものを条件にグループを作成することはできず、条件に加えたい値がEvent,Eventに紐づくParameter,UserPropertyに入れられない場合作りたいグループが作ることができません。
例えば、
種類が異なるDBを使用してるプロダクトで某DBに機械学習により計算された値が入るとします。
ある値をグループ作成時の条件に加えたいがEventに紐づくParameter,UserPropertyに加えることもできないという状況の場合BigQueryにtable(table_1など)を作成し某DBの値を作成したテーブルに流す仕組みを作ってあげればImport segmentsで作りたいグループが作成可能になります。
Audiencesとの違いのまとめ
位置付け的にはImport segmentsはAudiencesを包括するものと思っております。
(Audiencesで作成可能なのはImport segmentsだと思ってるため)
Audiences,Import segmentsどちらでも作りたいグループを作ることが可能な場合は
Import segmentsよりグループを作りやすいAudiencesで作るのが良いと思います。
Audiencesでは作成することが厳しい場合
以下手順を踏んでどちらを使うかを検討するのが良さそうです。
(個人的に作りやすい方に倒したいのでAudiencesで作れないかの手順になります。
1.Event,Eventに紐づくParameter,UserPropertyに詰めることができないか?を検討
2.できるならAudiences, できないならImport segmentsを使用
Author And Source
この問題について(【Firebase】Import segmentsの紹介とAudiencesとの比較), 我々は、より多くの情報をここで見つけました https://qiita.com/giiiita/items/dc564d897572e51a3600著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .