トリガー型タスクの作成（クライアント）

最終更新 2026/10/03

1. 機能の概要

サーバートリガー型エンゲージタスクでは、サーバーへのデータレポーティングの即時性に制約があるため、オフライン寄りのゲームで秒単位のトリガー応答が求められるシナリオには対応しきれません。そこで、バージョン4.4から、ThinkingData SDKの機能を活用し、エンゲージモジュールに「クライアントトリガー型タスク」をリリースしました。アプリ内での新規ユーザー登録やキャラクター作成などのシナリオにおけるミリ秒単位のトリガーの要件に対応し、リアルタイムのA/B分流にも対応しています。

また、エンゲージモジュールはクライアントSDKを介してAppと直接通信するため、webhookのサービスチャンネル経路を別途開発する必要なく、エンゲージタスクのパラメータを配信できます。

• データの流れ

元の画像を見る

2. 代表的なシナリオ

シナリオ	シナリオの説明	トリガールール
新規ユーザー - 初心者ガイドのA/Bテスト	新規ユーザーを対象に、異なる初心者ガイドのフローでA/Bテストを行い、最も効果の高い初心者ガイドのフロー戦略を最終的に決定して全量に反映します	ユーザーの起動時にゲームのユーザー識別IDが生成され、アプリの起動に成功した（ゲームプログラムの読み込みが完了した）とき、またはキャラクター作成やアカウント登録などを行ったときに、すぐに初心者ガイドのフローのグループ戦略を配信します
対局中または対局終了後のリソースパックの配信	ボードゲーム・カードゲームなど「トークン」の破産があるゲームで、対局中または精算後に破産した時点で、すぐにその「トークン」のリソースパックをプッシュします	対局のリソース変化：対局中は一般にアイテムの変化値（あるアイテム消費が現在のアイテム保有量を超えたか）を判定し、精算時は一般に変化後の値（<=0、またはこの種の試合の参加チケットに満たないか）を判定します
	数値育成系のゲームで、プレイヤーがステージで（毎回）連続して失敗した後のステージ精算ページで、育成に必要なリソースパックをすぐにプッシュします	連続失敗するたびに、育成ラインごとの状況に応じて異なるリソースパックをプッシュします（複数の育成ラインのリソースパックの条件を同時に満たす場合は、優先度のロジックがあります）
オフライン寄りの製品	オフライン寄りの製品では、クライアントの設定変更にパッケージの再リリースが必要な場合がありますが、クライアントSDKを使ってホットアップデートでリリースできます（起動時または再ログイン時に能動的に取得） よくあるシナリオは、ポップアップ、リソース枠、テロップなどです。	アプリの起動時、またはその他のクライアントの行動イベント

3. 接続の流れ

元の画像を見る

• 接続シナリオの確認：クライアントトリガー型で解決したい業務シナリオ（パック、初心者向けA/Bテストなど）を計画します。シナリオが決まったら、ThinkingAIのカスタマーマネージャーに連絡して、その後の接続のサポートを受けることができます。
• SDKの接続：詳しくはクライアントトリガー型の技術接続ドキュメントを参照してください。iOS/Android/ミニゲームのプラットフォームに対応しています。
• クライアントチャンネルの作成とテスト：AEのエンゲージモジュールを開き、エンゲージ設定 > チャンネル設定 > クライアントチャンネルページに進んでクライアントチャンネルを作成します。詳しくはクライアントチャンネル設定を参照してください。
• タスクの作成：チャンネルの接続が完了したら、エンゲージタスクの作成ページに進みます。業務の要件に応じて、トリガールールとプッシュ内容をカスタマイズできます。

ヒント

クライアントトリガー型タスクを使用するにはThinkingData SDKの統合が必要です。一部のトリガー処理機能には最小SDKバージョンの要件があるため、使用前に現在統合しているSDKのタイプとバージョンを確認してください。詳しくは本章の第6節「SDKバージョン別の対応機能」を参照してください。

4. クライアントトリガー型タスクの作成

入口：エンゲージ > エンゲージタスク > タスクを作成 > リーチ方法を選択 > クライアントリーチを選択 > チャンネルを選択 の後、エンゲージタスクの編集ページに入ります。

4.1 プッシュタイミング

クライアントトリガー型タスクは現在、【A完了後】と【A完了後にB未完了】のプッシュタイプに対応しており、「各完了」「連続完了したたびに」「順次完了したたびに」の3つのトリガー集計モードに対応しています。

ユーザーが指定した行動イベントまたは行動シーケンスを完了した後、すぐにプッシュでリーチします。たとえば、プレイヤーのレベルが50に達したら、レベル50の期間限定パックをトリガーします。

ヒント

クライアントトリガールールでは、クライアントで収集したイベントのトリガー計算にのみ対応しており、更新可能イベント、初回イベントとして識別されたイベントの計算には対応していません。

4.1.1 【A完了後】 — 各完了

「各完了」：タスク実行期間内に、ユーザーが ある行動を累積で完了するたびに プッシュが1回トリガーされます

例：ユーザーがチャージイベントを2回完了するたびに、割引クーポンを1枚プッシュします

• 選択した開始・終了時間内で、日/週/月ごと、またはタスク実行期間内である行動を累積で完了するたびに集計し、その後にプッシュでリーチできます
• 単一イベントの複数回によるトリガールールと、行動イベントのプロパティによるフィルターに対応しています
• カスタムの日次/週次/月次の開始・終了時刻を設定できます。たとえば、5:00→翌日5:00を1日、毎週水曜日5:00→翌週水曜日5:00を1週とする設定です

• トリガー条件を「条件1 または 条件2 を完了するたびに」と設定した場合、いずれかの条件がトリガーされたときに、他の条件の計算ウィンドウを閉じるかどうかを設定できます。

4.1.2 【A完了後】— 連続完了したたびに

「連続完了したたびに」：タスク実行期間内に、ユーザーがあるイベントを 複数回連続で完了するたびに、その間に別のイベントを行っていなければ（「実行していなかったイベントを追加」で設定可能）、プッシュが1回トリガーされます。

例：2時間以内に、レベルアップに2回連続で失敗するたびに、その間にチャージしていないユーザーにパックをプッシュします

• 選択した開始・終了時間内で、日/週/月ごと、またはタスク実行期間内で指定したイベントを複数回連続で完了するたびに集計し、その後にプッシュでリーチできます
• 単一イベントの複数回によるトリガールールと、行動イベントのプロパティによるフィルターに対応しています
• 関連プロパティ、時間ウィンドウ、実行していなかったイベントを追加できます
• カスタムの日次/週次/月次の開始・終了時刻を設定できます。たとえば、5:00→翌日5:00を1日、毎週水曜日5:00→翌週水曜日5:00を1週とする設定です

4.1.3 【A完了後】 — 順次完了したたびに

「順次完了したたびに」：指定した行動シーケンスを順番どおりに完了するたびに、プッシュが1回トリガーされます。

例：2時間以内に、「ログイン-ガチャ-課金」を順番どおりに完了したユーザーにパックをプッシュします

• 選択した開始・終了時間内で、日/週/月ごと、またはタスク実行期間内で指定した行動シーケンスを順番に完了するたびに集計し、その後にプッシュでリーチできます
• 複数のイベントトリガールールと、行動イベントのプロパティによるフィルターに対応しています
• カスタムの日次/週次/月次の開始・終了時刻を設定できます。たとえば、5:00→翌日5:00を1日、毎週水曜日5:00→翌週水曜日5:00を1週とする設定です

4.1.4 【A完了後にB未完了】

ユーザーが指定した行動Aを完了し、一定時間内に行動Bを完了しなかった後に、プッシュでリーチします。

たとえば、プレイヤーがある期間限定パックを獲得し（A完了）、0.5時間以内に購入を完了しなかった（B未完了）。この場合に、アプリ内メッセージをトリガーして、パックの有効期限がまもなく切れることを知らせます。

ヒント

ユーザーがA条件を1回完了するたびに、独立した観察期間が開始され、その期間内にB条件を完了したかどうかが判定されます。ユーザーがいずれかの観察期間内にB条件を完了すると、プッシュが1回トリガーされ、残りのすべての観察期間はただちに終了します。

4.2 プッシュ制御

4.2.1 頻度コントロール

頻度コントロール により、一定期間内にユーザーが受信できるプッシュの最大回数を制限できます。次のいずれかを選択できます：

• 1回の起動内に、ユーザーが受信できるプッシュの最大回数（1回の起動とは、アプリを開いてから終了/強制終了するまでを指します。アプリ画面を離れてバックグラウンドに移行しても、1回の起動内とみなされます）
• タスク実行期間内に、ユーザーが受信できるプッシュの最大回数（たとえば、タスク実行期間内に1回のみ）
• X日/週以内に、ユーザーが受信できるプッシュの最大回数（スライディングウィンドウ。たとえば「7日以内に1回のみ」は、直近7*24時間以内に1回のみを意味します）
• X日 / 週 / 月ごとに、ユーザーが受信できるプッシュの最大回数（ローリングウィンドウ。たとえば「毎週1回」は、各暦週内に1回のみを意味します）

たとえば、ゲーム内のキャンペーンが週単位で更新され、トリガールールが「プレイヤーが毎週ゲームモードへの参加回数30回を超えたら関連アイテムを1回プッシュする」だとします。同時に、そのプレイヤーが毎週1回しかプッシュを受信しないようにしたい場合は、開始・終了時間で「毎週」の累積完了を選択し、頻度コントロールで毎週1ユーザーあたり最大1回のプッシュを受信するよう設定します。週の開始日をカスタマイズすることもできます。

ヒント

クライアントトリガー型タスクはクライアントSDKが計算を実行するため、クライアントで収集したイベントの計算にのみ対応しています。ユーザーが複数のデバイスでログインしている場合、トリガーと頻度コントロールは端末デバイスごとに独立して計算されます。

4.3 ターゲットユーザー

ターゲットグループをカスタマイズするか、トリガー条件を満たすすべてのユーザーを対象にプッシュするかを選択できます。

4.3.1 カスタムコホート

ユーザーの行動がトリガーされた後、そのユーザーがターゲットユーザーグループに属するかを判定し、ターゲットユーザーの条件を満たすユーザーにプッシュします。即時性の違いによって、リアルタイム計算のターゲットユーザーグループと、1時間単位で更新されるターゲットユーザーグループに分かれます。

リアルタイム計算のターゲットユーザーグループ

• トリガー後、ターゲットユーザーに属するかどうかをリアルタイムで計算します

• 次の条件ではリアルタイム計算に対応しています：

  • ターゲットユーザーの条件で、リアルタイム計算の対応しているユーザープロパティとコホートのみを使用している場合
  • リアルタイム計算に対応するユーザープロパティ：定義にタグや、リアルタイムで利用不可な参照テーブルのプロパティを含まないもの
  • リアルタイム計算に対応するコホート：コホートのサイズが規定の上限（デフォルトは200万ユーザー）を超えないもの

• ターゲットユーザーの条件でリアルタイム計算に対応するコホートを使用している場合、「ルール変更」をクリックして、そのコホートの更新計算頻度（デフォルトは12時間ごとに更新）を変更できます

定期計算のターゲットユーザーグループ

• 「定期計算」とは、指定した計算頻度でターゲットユーザーグループを定期的に更新・計算することです。行動がトリガーされた後、直近の計算結果に基づいて、ユーザーがそのターゲットユーザーグループに属するかを判定します。
• ターゲットユーザーグループの条件にイベント、タグ、リアルタイム計算に対応していない参照テーブル、規定の上限を超えるコホートが含まれる場合は、定期計算のみに対応しています。
• 「ルール変更」をクリックして、ターゲットユーザーグループの更新頻度（デフォルトは12時間ごとに更新）を変更できます

コホートの更新は一定の計算リソースを消費します。不要な計算リソースのコストを避けるため、業務シナリオに合わせて適切な更新頻度を選択してください。

4.3.2 すべてのユーザー

トリガー条件を満たした後は、ユーザーをさらに細かくフィルターせず、トリガー条件を満たしさえすればプッシュを実行します。

4.3.3 人数の推定

セグメント条件を設定したら、 推定 をクリックしてターゲットユーザー数を推定し、エンゲージタスクがカバーする可能性のあるユーザー範囲を評価できます。

推定人数をできるだけ実際の値に近づけるため、推定では、ターゲットユーザーの条件を満たし、かつ 使用するリーチチャンネルの送信IDが空でない（つまり正常にプッシュできる）ターゲットユーザーの数を計算します。

4.4 クライアント条件

サーバートリガー型タスクとは異なり、クライアントトリガー型タスクでは、AEのデータアセットに加えて、クライアントを通じてより即時性の高いクライアントパラメータも取得できます。クライアントパラメータにはThinkingData SDKが取得できる環境パラメータが含まれます。さらに、TDRemoteConfig SDK が提供するSETパラメータインターフェースを使って、ゲーム内の業務パラメータをSDKのローカルにSETすることもできます（詳しくは クライアントトリガー型 SDK 接続ドキュメント を参照してください）。こうしたパラメータは、トリガー型タスクのローカルでの条件判断に使用できます。使用の流れは次のとおりです：

• SDKが公開しているインターフェースでカスタムパラメータをSETし、そのカスタムクライアントパラメータをAEの管理画面に追加します（詳しくは クライアントパラメータ を参照してください）

• クライアントパラメータを使ってエンゲージタスクで「クライアント条件」を設定します。この条件はクライアントSDKに直接配信され、ユーザーの行動がトリガールールを満たしたときに、現在クライアントが保持しているパラメータが制限条件を満たすかを即座に判定します。これにより、よりリアルタイムな条件判断を実現できます。

4.5 プッシュ構成

4.5.1 A/B テストの設定

トリガー型タスクはA/Bのスプリットテストと勝者総取りテストに対応しています。詳しくは次の章を参照してください：A/Bテスト

また、クライアントトリガー型では、「ユーザーID（クライアント）」または「アカウントID」を分流主体として選択できます。

4.5.2 頻度制御管理

複数のエンゲージタスクで同じリーチ方法（チャンネル）を使用する場合は、ユーザーへの過度な干渉を減らすため、1ユーザーが一定期間内に同種のチャンネルから受信するプッシュの最大回数を制限できます。

4.6 プッシュ内容

クライアントトリガー型は現在、多言語に対応していません。多言語でのプッシュが必要な場合は、ThinkingAIのCSMに連絡してソリューションを入手してください。

選択したリーチチャンネルに応じて、エンゲージ戦略に合ったリーチ情報の内容を入力できます。ユーザープロパティを挿入してパーソナライズした文面を作成したり、テスト送信でプッシュ効果をすぐにプレビュー・確認したりできるほか、必要に応じて頻度制御管理を有効にしたり、タスクのホワイトリストを設定したりすることもできます。

4.6.1 パーソナライズコンテンツ

リーチ内容にユーザープロパティまたはクライアントパラメータを挿入できます。リーチ内容に応じて、ユーザープロパティや設定したクライアントパラメータを必要に応じて挿入すれば、パーソナライズしたコンテンツをプッシュできます。たとえば、リーチ内容にユーザーのニックネームのプロパティを挿入すると、ユーザーが実際に受け取るメッセージにはそのユーザーのニックネームが含まれます。

4.6.2 テスト送信

タスクを審査に提出する前に、 テスト送信 でプレビューし、今回のエンゲージタスクのプッシュ内容に誤りがないことを確認できます。

クライアントトリガー型のテスト送信にはテストデバイスが必要です。テストデバイスを選択し、デバッグモードを有効にしてください。デバッグモードの有効化方法はクライアントトリガー型SDK接続ドキュメントを参照してください。

トリガールール、頻度コントロール、クライアント条件、プッシュ内容をテストできます。テスト内容を設定したら、テストデバイスを選択して 送信 をクリックしてください

4.6.3 トリガー値の使用

プッシュタイプとして「A完了後」を選択した場合、トリガー条件の集計値やトリガー時のイベントプロパティ値をプッシュ内容のフィールド値として定義でき、よりきめ細かなエンゲージ戦略を実現できます。

利用シーンの例：

• ステージで連続して失敗した場合に、該当するステージIDを渡し、そのステージの難易度を動的に配信します（上図のとおり）
• ゲームのシナリオで、プレイヤーがショップでクリックした商品タイプに基づいて、その商品タイプの割引クーポンをプッシュする（例：スキン、ヒーロー、ペット、武器などのアイテムタイプを好むプレイヤーに、そのアイテムタイプの割引クーポン（スキン割引クーポン、武器割引クーポンなど）をプッシュする）
• プレイヤーがあるリソースを累計で消費した数量を集計し、その消費量に基づいてリソースパックの内容を動的に配信する
• ライブ配信系製品のシナリオで、プレイヤーがフォローしている配信者がオンラインになったときに配信者のidを引き継ぎ、プッシュ内容で配信者idをもとに最終的なホームページURLを組み立てて、プレイヤーが該当する配信者のページに直接アクセスできるようにする

4.7 目標設定

リーチ後にユーザーが指定のイベント行動を完了した場合をコンバージョンとみなすよう設定し、エンゲージタスクの効果評価に使用します。

主要目標を1つと副次目標を2つ、同時に設定できます。

4.8 指標設定

任意のリーチノード後の指標パフォーマンスを設定でき、エンゲージ効果の判断に役立ちます。

具体的な使い方は次の章を参照してください：タスク効果分析

5. 機能 FAQ

1. クライアントトリガー型エンゲージタスクの数に上限はありますか？

   仕様：1つのプロジェクトで、定期タスクは200個、サーバートリガー型タスクは30個、クライアントトリガー型タスクは30個まで作成できます

   現在、1つのプロジェクトで作成できるクライアントトリガー型エンゲージタスクは最大30個です。上限を引き上げたい場合は、運用保守担当者に連絡して変更を依頼してください。

2. トリガールールの開始・終了時間は何を意味しますか？

   開始・終了時間は、イベントAを完了する時間範囲の制限です。開始・終了時間外に発生したイベントAは、トリガールールの計算に含まれないと考えてください。

3. エンゲージタスクのタスク実行期間を手動で選択できないのはなぜですか？

   タスク実行期間 はタスクの開始時間と終了時間を表します。トリガー型タスクでは遅延プッシュの設定があるため、タスク実行期間 = イベントAの開始・終了時間 + イベントA・B間のインターバル + 遅延プッシュ時間 となり、自動的に計算されます。

4. 遅延プッシュとイベントA・B間のインターバル期間の「日」は、暦日ですか、それとも24時間ですか？

   日、時間、分はいずれも秒単位で計算されます。1日の遅延とは24時間の遅延、つまり86400秒の遅延を意味します。

5. クライアントパラメータのチャンネルにある「メッセージタイプ」とは何ですか？

6. SDKバージョン別の対応機能

機能	対応する最小TDstrategySDKバージョン
「各完了」で複数のOR条件によるトリガーに対応 「各完了」でイベントプロパティ値に基づくトリガーに対応 トリガーイベントのフィルターでプロパティタイプ リスト/オブジェクト/オブジェクトグループに対応 トリガーイベントのフィルター条件で2階層のネストに対応	1.2.0
順番に完了 A完了後にB未完了	1.3.0

7. 使用可能なデータアセットの説明

主要なステップ	使用可能なアセット
プッシュタイミング	イベント：SDKで収集したイベント イベントプロパティ：SDKで収集したプロパティ
ターゲットユーザー	イベント：データステータスが「正常」 イベントプロパティ：データステータスが「正常」 ユーザープロパティ：すべて コホート：コホートの計算タイムゾーンがタスクのタイムゾーンと一致していること。計算主体はユーザーID（#user_id） タグ：タグの計算タイムゾーンがタスクのタイムゾーンと一致していること。計算主体はユーザーID（#user_id）
プッシュ内容	ユーザープロパティの挿入：リアルタイム利用可能なもののみ