目录
此内容是否有帮助?

# データアクセスの準備

基本知識では、データアクセスを実施する前に理解する必要があるデータルールについて説明します。必須情報には、アクセス前に準備する必要があるシステムパラメーターが記載されています。

Thinking Analytics（以下、TA）は、フルエンドのデータアクセススキームを提供します。

通常、TAにデータをアクセスするには3つのステップが必要です。まず、ビジネスニーズの整理に基づいて、データ収集案を整理します（必要に応じて、当社のアナリストが支援します）。そして、エンジニアがデータ収集案に基づいて実装を行う。最後にデータアクセスの正確性を検証します。このアクセスフローを次の図に示します。

データアクセスの前に、TAシステムの基礎を理解することが重要です。このドキュメントでは、データアクセスに必要な知識の全体的な説明を行います。

このドキュメントのターゲットは、ビジネス担当者、エンジニア担当者、検証テスト担当者など、アクセスに関連するすべての方々が対象です。

# I.概要

TAはフルエンドのデータアクセススキームを提供します。主なアクセス方法は以下の通りです。

  • クライアントSDK：デバイス情報などサーバーと通信しないユーザーの行動データを簡単に収集
  • サーバーSDK：サーバと通信し、より正確なユーザーの行動データを収集
  • データインポートツール：通常、履歴データインポートに使用。サーバーSDK、LogBusが一般的に使用されます

データアクセスは、サーバーSDKとLogbusの併用をお勧めします。データ導入の安定性、リアルタイム性、効率の面でより優れています。

Logbusでサポートされない履歴データインポートする必要のある場合、DataXを用いてインポートすることを検討してください。DataXは常駐サービスではなく、新しいデータの生成を監視してタイムリーにインポートすることができないため、データのリアルタイム性を保証することはできません。DataXの利点は、簡単な操作で複数のデータソースから異なるデータインポートをサポートすることです。

FilebeatとLogstashを使用して履歴データを収集し、ログデータをTAにインポートする場合は、Filebeat+Logstashシナリオを使用することも可能です。

データ収集ソリューションを設計するときは、お客様のビジネスの状況に応じて、お客様の製品の技術アーキテクチャとビジネスニーズに合ったソリューションを選択できます。疑問点があれば、お気軽にご連絡ください。

# II。基礎知識

# 2.1 TAデータモデル

データアクセスを行う前に、まずTAのデータがどのようなものであるかを理解する必要があります。

データ収集案の設計は実際に業務目標に基づいてどのユーザー行動イベントを収集するかを決定する過程です。例えば、ユーザーの課金状況を分析する場合、収集するのはユーザーの課金行動データです。。ユーザー行動データは、誰(WHO)、いつ(WHEN)、どこで(WHERE)、どのような方法で(HOW)、課金行動(WHAT)を行ったかに分解できます。

ユーザ行動データは、TAにおいて、ユーザ関連データおよびイベント関連データに編成され、ユーザテーブルとイベントテーブルにそれぞれ格納されます。

ユーザーデータは主にユーザーの状態と頻繁に変化しない属性を記述するために使用されます。一方、イベントデータは、特定の行動イベントに関連する情報を記述するために使用されます。

データアクセスのシナリオでは、ユーザーデータの報告をトリガーするタイミングと、イベントの報告をトリガーするタイミングを決定する必要があります。ユーザーデータとイベントデータの詳細については、ユーザープロパティとイベントプロパティをご確認ください。

我々が提供するすべてのデータアクセスガイドでは、イベントデータとユーザーデータをそれぞれ報告する方法を紹介しています。

# 2.2ユーザ識別ルール

ユーザーデータまたはイベントデータごとに、そのデータがどのユーザーに属するかを明確にする必要があります。アカウントシステムがない場合では、デバイスに関連するIDを使用してユーザーを一意に識別できます。しかし、アカウントシステムのある場合では、一人のユーザーが複数のデバイスでデータを生成する可能性があり、分析では複数のエンドでのユーザーのデータを結合して分析する必要があるため、デバイスに関連する一意のIDは適用されません。

上記の2つの可能性を処理するために、データアクセスの過程で、2つのユーザIDを組み合わせてユーザを識別する必要があります。

  • **ゲストID(#distinct_id)****：**デフォルトでは、クライアント側でランダムなゲストIDを生成してユーザーを識別し、ゲストIDを読み取ったり、変更したりするインターフェイスも提供します。
  • **アカウントID(#account_id)****：**ユーザーがログインしたときに、アカウントIDを設定できます。アカウントIDによって複数のデバイスのデータを関連付けることが可能です。

それぞれのデータには、ゲストIDまたはアカウントIDが含まれている必要があります。クライアントSDKはデフォルトでランダムにゲストIDを生成し、ログインインターフェイスを呼び出してアカウントIDを設定した後、ゲストIDとアカウントIDを同時に送信します。サーバーから報告するときは、少なくとも1つのIDを入力する必要があります。

TAバックグラウンドでは、ユーザーを識別する一意のID、TAユーザーID（#user_idフィールド）が発行されます。データを受信すると、指定されたユーザー識別ルール、新しいユーザーを作成したり、既存のユーザーにデータを結合したりします。

ユーザー識別ルールは非常に重要で、ユーザーIDを正しく設定しないと、データが誤ったユーザーに結合され、分析効果に影響を与える可能性があります。アクセスする前に、このルールをよく理解し、データ収集スキームでユーザー識別スキームを明確にしてください。

# 2.3データ形式

どちらの方法でデータにアクセスしても、データ受信側に送信するときは統一されたデータ形式と同じデータ制限が適応されいます。データルールでは、データ形式と対応するデータ制限について詳しく説明します。

SDKを介してデータをドッキングする場合は、対応するインターフェイスを呼び出すだけで、SDKはデータを必要なデータ形式にまとめて報告します。データインポートツールまたはRestful APIデータにアクセスする場合は、データルールの説明に従ってデータ形式をまとめて報告する必要があります。

データ形式については、命名規則とデータ型に特に注意が必要です

  • 命名規則:イベント名と属性名はアルファベット、数字、下線しか含まれません_、アルファベットで始まり、50文字を超えてはいけません
  • プロパティ値データ型:
TAデータ型
 サンプル値
 値の説明
 データ型
数値
 123,1.23
 データ範囲は-9E15~9E15
 Number
テキスト
 "ABC","
Tokyo
"
 文字のデフォルトの上限は2KBです
 String
時間
 "2019-01-01 00:00:00","2019-01-01 00:00:00.000"
 "yyyy-MM-dd HH: mm: ss.SSS」または「yyy-MM-dd HH: mm: ss」は、日付を表すために、「yyy-MM-dd 00: 00: 00」
 String
ブール
 ture、false
 -
 Boolean
リスト
 ["a","1","ture"]
 リスト内の要素は、リスト内で最も多い文字列型
 Array(String)
オブジェクト
 Hero_name:"劉備", hero_level: 22, hero_equipment:["雌雄二股剣","の呂"], hero_if_support: False}
 オブジェクト内の各サブ属性(Key)には独自のデータ型があり、値の説明は上の対応する型の通常属性・
オブジェクト内の最大100個のサブプロパティ
 Object
オブジェクト
配列
 [{hero_name:"劉備", hero_level: 22, hero_equipment:["雌雄二股剣","のルー"], hero_if_support: False},{hero_name:"劉備", hero_level: 22, hero_equipment:["雌雄二股剣","のルー"], hero_if_support: False}]
 オブジェクトグループ内の各サブ属性(Key)には独自のデータ型があります。値の説明は上の対応する型の通常属性
オブジェクトグループ内の最大500個のオブジェクト
 Array(Object)

注: TAバックグラウンドでは、属性値のタイプは、最初に受け取った属性値のタイプに基づいて決定され、データ内の属性の値のタイプが以前に決定されたタイプと一致しない場合、属性は破棄されます。

TAのバックグラウンドでは、特定のプロパティ名が#で始まります。プリセットプロパティは特に設定する必要はなく、SDKはデフォルトで取得します。具体的には、プリセット属性とシステムフィールドを参照ください

特に、データ形式やデータ型が正しく設定されていない場合、データを保存できないことに注意してください。そのため、アクセス段階とアクセス後、埋め込み管理モジュールでデータの報告の正確性を検証または観察し、発生した問題をタイムリーに修正する必要があります。

# 3、必要な情報を確認する

正式にデータアクセスを行う前に、次の情報が準備されていることを確認する必要があります。

  1. APP ID: TAバックグラウンドでプロジェクトを作成するときにプロジェクトのAPP IDが生成され、プロジェクト管理ページでも確認できます。
  2. データ受信側アドレス
  • SaaS型クラウドサービスを使用する場合、受信側のアドレスは次のとおりです。
    • https://ta-receiver.thinkingdata.io
  • 個別構築の場合、プライベートクラスター(またはアクセスポイント)にドメインをバインドし、SSL証明書を構成します。
  1. 受信側のアドレス
  2. ブラウザアクセス： https://YOUR_RECEIVER_URL/health-check
  3. ページリターン ：ok が表示されていれば、正しく設定されています
  4. データ収集スキーム
  • データアクセスの方法
    • クライアントSDK、サーバーSDK、データインポートツール、またはいくつかのシナリオを組み合わせる方法などがあります。
    • アクセスするデータの内容とトリガータイミングを確認