このページは Cloud Translation API によって翻訳されました。

Engage SDK に関するよくある質問

公開に関するよくある質問

コンテンツ公開ジョブを管理するのは誰ですか？

アプリデベロッパーがコンテンツ公開ジョブを管理し、Engage サービスにリクエストを送信します。そうすることで、デベロッパーパートナーは、ユーザーにコンテンツを公開するタイミングや方法をより細かく制御できます。これにより、コンテンツを公開するためにパートナーアプリを頻繁に起動する必要がなくなります。

デベロッパーはすべてのクラスタタイプを公開する必要がありますか？

技術的には、クラスタを 1 つだけ公開する形でも問題ありませんが、複数追加することを強くおすすめします。複数追加しないと、コンテンツをアピールする機会を逃すことになります。各カテゴリのすべてのクラスタタイプを公開することを強くおすすめします。

デベロッパーパートナーは、アプリの実行中、ワークマネージャーを使用してデータをどのくらいの頻度で公開する必要がありますか？

この点はデベロッパーパートナーが判断します。一般的なおすすめコンテンツについては 1 日に 1 ～ 2 回公開することをおすすめします。ショッピングカート、再注文、その他の継続コンテンツについては、イベント駆動型の方法を使用することをおすすめします（たとえば、ユーザーがカートに商品を追加したときや、映画を途中で停止したときのコールバックとしてワーカーを開始します）。ソーシャル アプリでは、アプリの使用後に更新されたおすすめクラスタを公開することが重要です。ソーシャルアプリのユーザーは最新の推奨事項に関心があり、理想的には投稿を 1 回だけ見たいと考えています。

デベロッパーが削除 API を呼び出すタイミングはいつですか？

削除 API は、公開するコンテンツがない場合にのみ呼び出す必要があります。コンテンツを置き換えるために、削除 API と公開 API を後から呼び出すことはしないでください。公開 API は以前のコンテンツを自動的に削除します。

ブロードキャストインテントに関するよくある質問

Android アプリのデベロッパーがブロードキャストインテントに登録する必要があるのはなぜですか？

ユーザーに最新のコンテンツを提供するには、ユーザーがそのアプリを頻繁に使用していない場合でもデータ同期をトリガーできるよう、ブロードキャストインテントを使用する必要があります。

ブロードキャストインテントをテストできない

検証アプリは、権限付きのブロードキャストインテントのテストをサポートしていません。テスト中に権限を削除し、ステップ 6 で SDK を本番環境バージョンに切り替える前に権限を追加し直す必要があります。

バックグラウンド実行が許可されていません

ブロードキャストインテントの登録中に、次のようなエラーが発生することがあります。

Background execution not allowed: receiving Intent
{ act=com.google.android.engage.action.PUBLISH_RECOMMENDATION .. }

ブロードキャストレシーバを動的に登録する必要があります。

class AppEngageBroadcastReceiver extends BroadcastReceiver {
// Trigger recommendation cluster publish when PUBLISH_RECOMMENDATION broadcast
// is received
}

public static void registerBroadcastReceivers(Context context) {

context = context.getApplicationContext();

// Register Recommendation Cluster Publish Intent
context.registerReceiver(new AppEngageBroadcastReceiver(),
                         new IntentFilter(com.google.android.engage.service.Intents.ACTION_PUBLISH_RECOMMENDATION,
                         com.google.android.engage.service.BroadcastReceiverPermissions.BROADCAST_REQUEST_DATA_PUBLISH_PERMISSION,
                         /*scheduler=*/null));
...

}

ワークフローに関するよくある質問

SDK との統合中に、次のようなエラーが発生することがあります。

アプリ、クラスタ、エンティティレベルでの検証エラー

アプリ、クラスタ、エンティティレベルの概要には、検証エラーの数が表示されます。これらのエラーは、必須フィールドが欠落しているか、無効な値が指定されている場合に発生します。エラーメッセージは、関連する各フィールドの下に赤色で表示されます。APK を共有する前に、すべての検証エラーを修正し、正しさを確認します。

ディープリンクのテスト

ディープリンクはパッケージ名と関連付けられています。ディープリンクをテストするには、adb ツールの使用をおすすめします。

adb shell am start -W -a android.intent.action.VIEW -d <DEEPLINK URI> <PACKAGE NAME>

統合の影響を計算するにはどうすればよいですか？

ディープリンクは、アトリビューションをトラッキングするのに最適な方法です。ユーザーをアプリに誘導するディープリンク URL は、追加のトラッキングパラメータに配置できます（例: http://xx/deeplink?source_tag=engage）。

デベロッパーは、独自のトラッキングパラメータを追加し、影響を計算するためのアトリビューションを指定できます。

Engage for TV 2.0 に関するよくある質問

一般的な質問

Continue Watching 2.0 とは何ですか？

「視聴を中断したところから動画の続きをスムーズに再生できる」エクスペリエンスをさらに進化させたのが、Continue Watching 2.0（Video Discovery API）です。このアップグレードにより、視聴者はより多くのデバイスでコンテンツをシームレスに再開できるようになります。Google TV で映画を見始めて、通勤中にスマートフォンで続きを簡単に視聴できるのが、Continue Watching 2.0 の魅力です。

この新しいシステムは、Google エコシステム全体でスムーズでストレスのないエクスペリエンスを提供することで、視聴者のエンゲージメントと維持率を高めるように設計されています。

Continue Watching 2.0 を使用するメリットは何ですか？

回答: 「続きを見る 2.0」を使用すると、視聴者は使用しているデバイスに関係なく、コンテンツの続きを簡単に視聴できます。仕組みは次のとおりです。

Google 全体でシームレスな体験: Google TV で視聴を開始し、Android スマートフォン、iPhone、Android タブレットでシームレスに視聴を続けることができます。アプリをまだインストールしていないデバイスでも動作します。
エンゲージメントとユーザー維持率の向上: 「続きを見る 2.0」は、新しいデバイスでもユーザーをアプリに呼び戻すのに役立ちます。ユーザーがお気に入りの番組を再開できるようにすることで、視聴を継続してもらえる可能性が高まります。
リーチの拡大: Google TV だけでなく、Play キューブやその他の Google メディアアプリなど、他の Android メディアエクスペリエンスでも [続きを見る] 2.0 が機能します。
下位互換性: 以前の [次のおすすめ] 機能をすでに使用している場合でも、問題はありません。「続きを見る 2.0」は下位互換性があるため、既存の統合は引き続き機能します。

重要な注意事項: 新しい「続きを見る」インテグレーションはすべて、「続きを見る」2.0 を使用する必要があります。以前の「複数デバイス間次のおすすめ」システムは段階的に廃止されます。

Continue Watching 2.0 に対応しているサーフェス

Google TV
Android TV（デバイス上のみ、Engage SDK をサポート）
Google TV Android モバイルアプリ
Google TV iOS モバイルアプリ
Play キューブ
Google エンターテイメントスペース
iOS デバイス（REST API 統合）。

Engage SDK は「続きを見る 2.0」に対応していますか？

はい。Engage SDK は「続きを見る 2.0」用です。Continue Watching 2.0 と統合するために必要です。

「続きを見る 2.0」はすべてのユーザーが利用できますか？

Continue Watching 2.0 は段階的にリリースされます。

早期アクセス: 早期アクセスプログラム（EAP）を通じて、一部のパートナーにのみアクセス権を付与します。
アクセスを拡大: すべてのデベロッパーが「続きを見る 2.0」をまもなく利用できるよう、Google は取り組んでいます。

スムーズかつ成功裏にリリースできるよう、ロールアウトを管理するための保護措置が講じられています。これには、「続きを見る 2.0」側の許可リストと、Engage SDK 内の個別のチェックの両方が含まれます。EAP パートナーであるか、まもなくオンボーディングを希望される場合は、Engage SDK の統合を開始する前にアクセス権を設定できるよう、Google までご連絡ください。

推奨される画像のサイズはありますか？

エンティティの作成セクションで、画像要件が更新されました。

この新しい API ドキュメントを使用すると、Google サーバーがクライアントから取得した「続きを見る」のデータがすべてのデバイスに反映されますか？

新しい API には、[続きを見る] に次のような大きなメリットがあります。

Google TV 間でシームレスな視聴体験: ユーザーは、1 台の Google TV で視聴を開始し、同じアカウントでログインしている別の Google TV で再開できます。この機能は、古いバージョンの Android TV でも動作します。
モバイルアプリの統合: [続きを視聴] は Android と iOS の Google TV モバイルアプリで利用できるため、ユーザーはテレビとモバイルデバイスをシームレスに切り替えることができます。
ユーザー維持率の向上: アプリがインストールされていないデバイスや、ユーザーがログインしていないデバイスでも、「続きを見る」によってユーザーにアプリへの再エンゲージメントを促し、維持率を高めることができます。
他のプラットフォームへの拡大: この統合により、視聴を続ける機能が Android、Play Cubes、タブレットなどの他の Google メディアプラットフォームや、Android の他の Google メディアアプリやサーフェスにも拡張され、デバイス間のユーザーエンゲージメントが最大化されます。

継続クラスタに公開できるエンティティの数に上限はありますか？

各デベロッパーパートナーは、継続クラスタ内で最大 5 個のエンティティに制限されます。この制限は、複数のメディアプロバイダが共有するスペースである Google TV の [続きを見る] 行にコンテンツを公平に配信するためのものです。

6 個以上のエンティティを公開しようとするとどうなりますか？

エンティティ数が 5 個を超えている場合、EngageSDK は公開リクエストを拒否します。公開を成功させるには、リクエスト内のエンティティの数を減らす必要があります。ユーザーが視聴を中断したエンティティのみを含める必要があります。ほとんどの場合、そのようなエンティティは少数です。このようなエンティティが 5 つ以上ある場合は、最新のものを選択して公開できます。

エンティティの数に上限があるのはなぜですか？

Google TV の [続きを見る] 行には、さまざまなメディアプロバイダのコンテンツが表示されます。プロバイダあたりのエンティティ数を制限することで、ユーザーがすべての好きなソースから多様なコンテンツを選択できるようにし、公平でバランスの取れたユーザーエクスペリエンスを促進します。

確認アプリに関する質問

送信前に検証アプリでアプリをテストすることは必須ですか？

はい。APK を送信する前に、検証アプリでアプリをテストすることが不可欠です。

実装に自信をお持ちであることは理解しておりますが、「続きを見る」2.0 の統合には多くの複雑なコンポーネントが含まれています。検証アプリはセーフティネットとして機能し、潜在的な問題を早期に検知して、長期的に貴重な時間と労力を節約します。

スムーズなリリースと優れたユーザーエクスペリエンスを保証するための簡単なチェックアップと考えてください。

問題を事前に特定して対処することで、不承認や再送信のストレスを回避できます。

APK を送信するには、アプリが検証プロセスに合格したことを示すスクリーンショットを含める必要があります。

統合時に注意すべき一般的な間違いは何ですか？

検証用アプリは、[続きを見る 2.0] の統合で発生する可能性のある問題を検出するように設計されています。開発者がよく遭遇する一般的なミスを次に示します。

すべてのコンテンツタイプ（映画、テレビ番組、ライブ配信、動画クリップ）の場合:

リンクがない: コンテンツのプラットフォーム固有の有効な URI（リンク）を指定してください。これらのリンクは、各プラットフォームでコンテンツを見つける場所をシステムに伝えます。
タイトルがない: すべてのコンテンツにタイトルを付けることを忘れないでください。これにより、ユーザーは視聴していた内容を特定できます。
画像のアスペクト比: コンテンツに関連付けられているすべての画像のアスペクト比が 16:9 に近いことを確認します。これにより、画像がさまざまな画面で正しく表示されます。

テレビ番組のエピソードの場合:

エピソードの情報をすべて入力する: 番組のタイトル、エピソード番号、シーズン番号を必ず入力してください。これにより、エピソードが整理され、ユーザーはシリーズ内を移動できます。
正確な再生位置: 前回の再生位置がエピソードの合計時間以下であることを再確認します。これにより、ユーザーは正しい場所から再開できます。

映画の場合:

正確な再生位置: テレビ番組と同様に、最後の再生位置が正確であることを確認します。

ライブストリーミング動画の場合:

配信者の情報: ライブ配信の場合は、配信者の名前を含めます。

動画クリップの場合:

クリエイター情報: 動画クリップのクリエイターを指定します。

注: 検証アプリはこれらの問題を検出し、アプリを送信する前に修正できるようにします。これにより、時間を節約し、ユーザーにスムーズなエクスペリエンスを提供できます。

アカウントとプロフィールに関する質問

アプリで匿名ユーザーのログインを使用しています。Continue Watching 2.0 で AccountProfile は引き続き必要ですか？

AccountProfile は、個々のユーザーアカウントを使用するアプリ向けに設計されています。ただし、お客様のアプリのように、匿名ログインに依存しているアプリもあることは承知しております。このシナリオでの Continue Watching 2.0 の動作は次のとおりです。

AccountProfile は技術的には必須ですが、アプリにユーザーアカウントシステムがない場合でも、続きを見る 2.0 を統合できます。
デバイス内での使用に限定: 視聴を続ける 2.0 のクロスデバイス機能は、さまざまなデバイスでユーザーを識別することに依存しています。匿名ログインではこの情報が提供されないため、この機能はユーザーの現在のデバイスに限定されます。
設定方法: この設定を行うには、デバイス間の同期を無効にする必要があります。これにより、[続きを見る] エントリは、コンテンツの再生を開始した特定のデバイスにのみ表示されます。

要約: 「続きを見る 2.0」は匿名ログインと統合できますが、ユーザーがコンテンツを再開できるのは同じデバイスのみです。

アプリが accountId と profileId の両方をサポートしている場合でも、accountId のみで profileId を使用せずに AccountProfile を使用できますか？

AccountProfile が正しく機能するには、accountId と profileId の両方が必要です。その理由は次のとおりです。

一貫した識別: accountId はユーザーを識別し、profileId はそのユーザーのアカウント内の異なるプロフィールを区別します（該当する場合）。両方を提供することで、[続きを見る] で各プロフィールに合ったコンテンツが正確に追跡され、表示されるようになります。
エラーの防止: 異なる API 呼び出しで accountId と profileId を一貫して使用しないと、予期しない動作やエラーが発生する可能性があります。たとえば、[続きを見る] にコンテンツを追加するときに両方を含め、コンテンツを削除するときに accountId のみを使用すると、システムが目的のアイテムを正しく識別して削除できない可能性があります。

Continue Watching 2.0 に profileId は必要ですか？

accountId は必須です。これにより、デバイス間でユーザーが識別されます。
profileId は、優れたユーザーエクスペリエンスを実現するうえで非常に重要です。技術的には省略可能ですが、サービスが複数のプロフィールをサポートしている場合（多くのストリーミングサービスがサポートしているように）、profileId を使用することを強くおすすめします。なぜ重要かprofileId がないと、[続きを見る] に同じアカウントの他のプロファイルのコンテンツが表示される可能性があります。これにより、ユーザーに混乱や不満が生じる可能性があります。
つまり、profileId を指定することで、[続きを見る] に各個人の視聴履歴が正確に反映されるようになります。アプリがアカウント内のプロファイルの概念をサポートしていない場合を除き、提供する必要があります。

Google は profileId をどのように使用しますか？

サービスでコンテンツを視聴するためのさまざまなプロフィールが提供されている場合、accountId と profileId は、デバイスで視聴したコンテンツをデバイスのログイン済み Google アカウントに関連付けるために使用されます。Google は、accountId-profileId の組み合わせに対して視聴中のコンテンツのデータを記録します。同じ Google アカウントでログインしている Google デバイスは、同じ関連付けられた accountId-profileId から最新の更新データを受け取り、[続きを見る] 行に表示します。

「続きを見る 2.0」を実装するには、アカウントのリンクが必要ですか？

アカウントのリンクは不要です。優先度が下げられ、関連するユースケースはすべて新しいデバイス利用資格 API でカバーされます。

デバイス間の同期に関する質問

ユーザーが同意した場合の「デバイス間で同期」とはどういう意味ですか？

ユーザーが [デバイス間で同期] に同意すると、視聴中のコンテンツが Google TV サーバーに保存され、ログインしているどのデバイスでも、中断したところからシームレスに再開できるようになります。同意しない場合、視聴履歴は現在のデバイスにローカルに保存されます。

「デバイス間で同期」を false に設定できますか？

UserConsentToSyncAcrossDevices フラグは、ユーザーの ContinuationCluster データがデバイス（テレビ、スマートフォン、タブレットなど）間で同期されるかどうかを制御します。このフラグが false に設定されている場合、続きを見るは同じデバイスでのみ行われます。

クロスデバイス機能を最大限に活用するには、アプリでユーザーの同意を取得し、SyncAcrossDevices を true に設定することを強くおすすめします。

Android 以外のデバイスで視聴履歴の共有に関するユーザーの同意を得る方法

デバイスをAndroid 以外のデバイスからサードパーティサーバーに共有されるデータポイントは何ですか？

同意はユーザー単位（プロフィールまたはアカウント単位）で収集されます。同意が得られると、エンゲージメントに基づく「続きを見る」ペイロードをどこにでも送信できるようになり、Google は、ユーザーが一部または次のエンゲージメントを行っているすべてのエンティティで、あらゆるデバイスでユーザーのユビキタスな再開状態を反映できます（すべてのデバイスやプラットフォームで同意を再度求める必要はありません）。パートナーは、プロフィール ID（Android に保存されたもの）に関連付けられたユーザーの最新の視聴継続状態（仕様に基づく）を送信します。

REST API に関する質問

REST API のドキュメントはありますか？

REST API の ETA は 2025 年 3 月です。これは、Continue Watching 2.0 デベロッパードキュメントに記載されています。

以前の Watch Next の質問

Video Discovery API は Watch Next API に代わるものですか？

Video Discovery API は、Watch Next API をサポートするすべての Android TV デバイスで下位互換性があります。すべてのデベロッパーは、Video Discovery API（Continue Watching 2.0）を使用して [続きを見る] 行に公開する必要があります。

テストと統合に関する質問

LastPlayBackPositionTimeMillis と duration の違いは何ですか？

LastPlayBackPositionTimeMillis は、ユーザーが視聴を停止した時点の再生時間（ミリ秒単位）を反映する必要があります（例: 10 分 5 秒の場合は 605000 ミリ秒）。エンティティの合計時間より大きくなることはありません。

一方、LastEngagementTime は、ユーザーがコンテンツを最後に使用したときのタイムスタンプです。

実行すべきテストケースは何ですか？

以下は、Google の QA が実施する Google TV のテストケースです。他のサーフェスでも同様のテストケースを実行できます。

20 分を超える動画を約 5 分間視聴します。アプリを終了します。[続きを見る] 行に動画カードが表示されます。注: CW では、サードパーティ製アプリごとに 5 枚のカードのみが表示されます。
[続きを見る] 行に新しく表示されたカードを選択すると、動画の適切なポイントから再生が再開される。注: 新しいコンテンツと古いコンテンツのどちらも、前回中断したところから再生が再開される
GTV デバイスでアカウントを変更すると、[続きを見る] 行のカードも変更されるはずです。現在のアカウントの動画のみが表示されるはずです。最近の順に並べ替えました。サードパーティ製アプリのプロフィール CW が混在します。注: GoogleAccount2 の CW には、GoogleAccount2 が視聴したサードパーティのコンテンツが表示されます
[戻る] ボタンでアプリを終了 > [続きを見る] 行にカードが表示されていることを確認
[視聴を続ける] 行で動画を非表示にします。非表示にしたコンテンツが 24 時間以上非表示のままで、24 時間後にアプリを開いても表示されないことをテストします。1 つのアイテムを非表示にしても、複数のアイテムが非表示にならないことを確認します。
[続きを見る] でのコンテンツの利用可能性（完全なメタデータ付き）: カード画像、アプリ名、タイトル、テレビコンテンツのシーズンとエピソード番号
[Check Progress] が進行状況バーに表示される
ユーザーがコンテンツを最後まで視聴したが、[続きを見る] にコンテンツが表示されない
未視聴のアイテムが [続きを見る] 行に表示されないことを確認する
CW アイテムが、アプリが最後に開かれた日時や最終日ではなく、スマートウォッチのアクティビティが発生した日時に基づいて時系列で並べられていることを確認します
CW カードのエピソードとシーズンの詳細が、エピソードコンテンツで視聴した内容と一致していることを確認します
完了した（クレジット以降の）アイテムが [続きを見る] に表示されないことを確認する
エピソード/映画/番組の視聴中にデバイスの電源をオフにする。「エピソード/映画/番組の視聴中にデバイスの電源を切ります。デバイスの電源をオンにしたときや、別のテレビで、CW が正しいカードを正しい位置に表示し、プログレスバーも表示することを確認する」
エピソード 1 を最後まで視聴したら、デバイスの電源をオフにして、
エピソード 1 がドロップし、[続きを見る] 行に再表示されない [2 台目のデバイスとテストデバイスの電源を入れた場合]
1. エピソード 2（利用可能な場合）が [続きを見る] 行に表示される [2 台目のデバイスとテストデバイスの電源を入れた場合]
シナリオ 1: TV1: Google アカウント: mom、サードパーティのアカウント / プロフィール: account 1 / profile_1。コンテンツを視聴し、CW データにサードパーティのアカウント 1/プロファイル 1 で視聴したコンテンツが表示されることを確認します。
TV2: GoogleAccount: mom。最初のシナリオの CW データを検証します。別のアカウントとしてサードパーティ製アプリにログインします。サードパーティのアカウント / プロファイル: account_2 / profile_2。コンテンツを視聴し、CW データにサードパーティのアカウント 2/プロファイル 2 で視聴したコンテンツが表示されることを確認する
GoogleAccount: mom。新しいデバイスケース /サードパーティ製アプリがインストールされていない。新しいデバイス（デバイスの FDR）で、Google アカウントで使用された最後に使用されたサードパーティ製アプリのデータが CW に表示されることを確認します。注: GAIA が他のデバイスのサードパーティプロフィールに関連付けられていない場合、CW 行にサードパーティコンテンツは表示されません
1. GoogleAccount: mom。新しいデバイスケース /サードパーティ製アプリがインストールされているが、ログインしていない。新しいデバイス（デバイスを FDR）で、CW が Google アカウントで使用された最後に使用されたサードパーティ製アプリのデータを表示することを確認します。
注: アプリがインストールされ、ログインされると、CW 状態には 3P アプリにログインしているアクティブな 3P ユーザーが反映されます。
1. 注: Google アカウントがサードパーティのプロフィールに関連付けられていない場合、[続きを見る] 行にサードパーティのコンテンツは表示されません

Google TV iOS アプリに [続きを見る] が表示されません。どうなっていますか？

iOS デバイスに [続きを見る] を表示するには、iOS ディープリンクを送信する必要があります。

「続きを見る」の情報を更新する頻度はどのくらいですか？[続きを見る] の情報は 15 秒ごとなど、頻繁に更新する必要がありますか？

いいえ。頻繁な更新はおすすめしません。その理由は次のとおりです。

パフォーマンスへの影響: 更新を継続的に送信すると、サーバーに不必要な負荷がかかり、システム全体の速度が低下する可能性があります。
不要なデータ: ユーザーが視聴している間、再生位置は常に変化します。数秒ごとに更新を送信すると、再生の再開に役立たない冗長なデータが大量に作成されます。

[続きを見る] の情報を更新するタイミング:

ユーザーの視聴状況の有意義な変化を捉えることに重点を置きます。主なシナリオは次のとおりです。

再生の一時停止または停止: ユーザーが視聴を一時停止または停止した場合は、現在の位置を保存する更新を送信します。
アプリが閉じられた場合またはバックグラウンドに移行した場合: ユーザーが動画の視聴中にアプリを終了した場合や別のアプリに切り替えた場合は、進行状況を保存するための更新を送信します。
アプリ内の [続きを見る] 行からアイテムを削除した場合

効率的に更新する方法:

時間指定の更新ではなく、動画プレーヤーまたはアプリのライフサイクル内のイベントを利用して更新をトリガーします。次に例を示します。

onPause、onStop: 動画の再生が一時停止または停止したとき。
onAppClose、onAppBackgrounded: アプリが閉じるか、バックグラウンドに移動したとき。

これらのガイドラインに沿って実装することで、リソースを効率的に使用しながら、ユーザーにシームレスな「続きを見る」エクスペリエンスを提供できます。