はじめに

Firebase Summit2020でFirebaseの新機能として
紹介された中で個人的に一番興味があったImport segmentsについて書いてみます

内容は以下２点になります
・Import segmentsについて簡単な紹介
・AudiencesとImport segementsの比較

Audiencesについてこの投稿で触れるので知らない方は以下記事をみていただけると幸いです！
Event, UserPropertiesを送っておくと戦略的に幅が広がる話

Import segementsについて

FirebaseProjectと連携してるBigQueryから
チームが定義したセグメントデータを利用できます。

このセグメントデータは
Cloud Messaging、RemoteConfigなどのFirebaseが提供する機能で使用できます。

これによりセグメントを対象に
通知であったりRemoteconfigの値を切り替えるなどの実装が可能になります。

Import segmentsのDocument

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の値を切り替えるなどの実装が可能

これは既存機能の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を使用