Google Data StudioのCommunity Connectorは接続する前にdataの正本と権限を分ける

Google Data StudioのCommunity Connectorは、reportへ表示したい外部dataをつなぐための仕組みです。connectorを作る前に、どのserviceのどの数字を正本とするか、誰が接続を管理するか、誰へreportを見せるかを決めます。chartが表示できることと、数字の意味やdataの所有が整理されることは別です。最初に、数字の出所と責任者を一つずつ対応させます。

Googleは、Community Connectorの開発programを始め、Google Apps Scriptでconnectorを作り、ほかの人が自分のdataへ接続できるよう共有できると案内しています。これは任意のdata sourceを可視化する入口になります。しかし、connectorを共有することは、data sourceの内容を自由に見せてよいという判断ではありません。接続する仕組み、dataを読む権限、reportを渡す範囲を分けて考えます。

connectorが読むdataとreportで見せる数字を分ける

connectorは、外部のdata sourceからGoogle Data Studioへdataを渡すために使います。reportは、そのdataの一部をtableやchartとして読むために使います。同じserviceへつながっていても、何を取り出し、どの期間で集計し、どの名前で表示するかはreportごとに決めます。connectorを入れれば、数字の定義まで自動でそろうわけではありません。

説明用の仮例として、予約を受ける事業者が、広告費と予約件数を同じreportで見たい場合を考えます。広告費のdataと予約dataが別のserviceにあるなら、まず各dataが何を一件としているかを確認します。広告費は配信日で集計され、予約は受付日で記録されるかもしれません。二つの数字を一つのchartへ置く前に、期間の基準、通貨、税込か税抜か、取消した予約を含めるかを決めます。

この確認をせずに、connectorで二つのdata sourceへつなぐと、同じ「予約数」という表示でも人によって意味が変わります。問い合わせを受けた件数なのか、予約が確定した件数なのか、来店した件数なのかは別です。reportの見た目を整える作業と、事業で判断に使う数字を定める作業を混ぜません。

connectorが取得できる項目を先に全部reportへ出す必要もありません。広告費と予約の関係を見たいなら、判断に必要な項目から始めます。読者の氏名、mail address、電話番号、社内のメモまで、数字を並べるためにreportへ渡す理由はありません。利用者が見る必要のないdataを減らすことと、reportの作成を諦めることは違います。

接続を作る人とdataを所有する人を分ける

Community ConnectorはGoogle Apps Scriptで作れます。codeを書ける人がconnectorを作ることと、外部serviceのaccountやdataを所有することは別です。制作会社や解析担当者がconnectorを作る場合でも、接続先のaccountを誰が管理し、利用を許可し、不要になった接続を止めるかは事業者側で決めます。

仮例の予約事業者が制作会社へreport作成を頼むなら、少なくとも三つを分けます。一つ目は、広告serviceと予約serviceのaccountを持つ人です。二つ目は、connectorとreportを作る人です。三つ目は、reportを見て予算や受付方法を決める人です。三つが同じ人とは限りません。担当が替わったときに、reportが見られなくなるのか、接続を直せるのか、数字を確認できるのかを書き残します。

connectorを共有して、別の人が自分のdataへ接続できるようにする場合も、共有するものを取り違えません。共有するのは、dataを読むための仕組みなのか、完成したreportなのか、reportの編集権限なのかで、確認する範囲が変わります。完成したreportを見せる相手が、外部serviceのaccountへ入る必要まであるとは限りません。必要な権限を一つずつ確認します。

accountのlogin情報を一つにまとめて渡す方法は、担当の記録を失わせます。誰が接続を変えたか、誰がdataを見たか、退職や委託終了のあとに誰が止めるかを確認しにくくなります。個人のaccountと役割を分け、必要な範囲で共有します。connectorの作成を急ぐことより、dataの入口を事業者が把握していることを優先します。

reportを渡す前に確かめる順序を決める

最初に、reportで答える質問を一つ決めます。たとえば「広告費に対して、受付済みの予約はどのくらいか」を見るなら、広告費、受付済みの定義、期間、見る人を決めます。次に、その数字の正本があるserviceとaccountを確認します。ここで正本が決まらない数字は、connectorでつないでも判断の根拠にしません。

次に、connectorが読む項目を小さな範囲で試します。取得した値が元のserviceの表示と合うか、日付の境目で数字が変わらないか、空欄や取消をどう扱うかを確認します。connectorのcodeが動いたことと、reportの数字が正しいことは別の確認です。元のserviceの数字と並べ、同じ条件で比べます。

reportを共有する前には、見る人ごとに必要な範囲を確認します。経営者が週ごとの予約数を見たい場合と、広告運用者が広告groupごとの費用を見たい場合では、必要な項目が違います。一つのreportへ全員分のdataを詰め込まず、判断する人と必要な数字を対応させます。見せない項目を決めることもreport設計です。

更新や不具合への対応も先に決めます。外部serviceの項目名やdata形式が変わったとき、誰がconnectorを確認するか、reportの数字が急に空になったとき、誰が元のserviceと比べるかを決めます。reportのURLを渡して終わりにせず、connector、data source、report、判断の担当を記録します。

最初の一手は、表示したいchartではなく、答えたい質問を一文で書くことです。その質問に必要な数字だけを挙げ、各数字について正本のservice、accountの管理者、集計条件、見る人を並べます。connectorは、その整理が済んだdataをreportへ渡すために使います。