Google Ads API v3 は、2021 年 2 月 10 日に提供を終了しました。それ以降、v3 API へのすべてのリクエストは失敗します。API アクセスに影響がないように、新バージョンに移行してください。
移行に役立つさまざまなリソースを準備しています。
アップグレードの際に疑問に思うことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。
- Google Ads API チーム、Thanet Knack Praneenararat
Apple がまもなく導入する App Tracking Transparency（ATT）ポリシーでは、他の企業のアプリやウェブサイトの一部の情報を広告目的で使う場合、その許可を得ることが必須となります。これには、すでにユーザーの同意を得ている場合も含まれます。iOS エコシステムのデベロッパーや広告主はまだ適応する方法を模索している状況なので、今日は Google がどのようにコミュニティの準備をサポートしているかについてお知らせします。
Apple が ATT を変更することにより、広告がどの程度コンバージョン（アプリのインストールや販売）を促進しているかを示す重要な指標の一部が見えなくなります。これは、広告主による広告インプレッションの価値評価や入札に影響します。そのため、Apple の ATT ポリシーが適用されると、アプリの発行元は、iOS での Google 広告の収益に重大な影響が発生する可能性があります。iOS の収益化率を向上するには、Google Mobile Ads SDK のバージョン 7.64 にアップグレードし、SKAdNetwork サポートなどの新機能を利用することをお勧めします。アプリの発行元が準備できることの詳細は、こちらをご覧ください。
Google は、iOS 14 で広告主がキャンペーンの結果を正確に測定できるように、業界と連携して、SKAdNetwork の改善に関するフィードバックを Apple に提供しています。改善が行われるまでの間は、最新バージョンの Google Analytics for Firebase にアップグレードし、SKAdNetwork サポートなどの新機能を利用することをお勧めします。また、すべての iOS のアプリ キャンペーンのパフォーマンスや成果を細かく監視し、必要に応じて目標を達成できるように予算や入札を調整することをお勧めします。アプリの広告主が準備できることの詳細は、こちらをご覧ください。また、一連のガイドは Learn with Google 教育シリーズに掲載されています。
広告主がウェブベースのコンバージョン目標に向けてディスプレイ、動画などのキャンペーンをしている場合、Apple の ATT ポリシーが適用される際に実績が変動する可能性があります。この期間には、推定コンバージョンを拡張してより多くの iOS 14 トラフィックに対応できるようにする予定です。
Apple のポリシーが適用されると、現在広告目的で ATT に該当する（IDFA などの）情報を利用しているいくつかの Google 製 iOS アプリで、その情報を利用できなくなります。そのため、Apple のガイドに従い、これらのアプリには ATT プロンプトは表示しません。私たちは、App Store のすべての Google 製アプリについて、Apple のガイドを理解してそれに準拠する作業を懸命に進めています。新機能やバグの修正などで Google 製 iOS アプリがアップデートされると、アプリの掲載情報ページで App のプライバシーに関する詳細情報が新しくなるのを確認できます。
Google は、常にユーザーとプライバシーを最優先しています。透明性、選択肢、制御は、ユーザーに対する私たちの献身の根底であり、それは広告でも同様です。Google は、プライバシーと選択肢が確かに尊重され、広告によってサポートされる幅広いコンテンツにアクセスでき、活発でオープンなアプリのエコシステムをこれからも守り続けます。集計ソリューションやオンデバイス ソリューションなどのプライバシー保護技術に注力し続けているのはそのためです。現在、エコシステム パートナーとともにウェブで開発しているプライバシー サンドボックスもその 1 つです。
この記事は Eric Bahna による Android Developers Blog の記事 "Expanding the reach of your Android Auto apps" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
昨年 12 月、Google Play ストアで新しい Android Auto アプリをクローズド テストに公開できる機能を開放しました。続いて 2021 年 1 月 28 日より、Google Play ストアで、ナビゲーション、駐車場、充電スポットのアプリをオープン テストトラックに公開し、アプリのユーザーを増やせるようになりました。
オープンテストでは、アプリをダウンロードできるユーザー数に制限はなく、メールアドレスの一覧を管理する必要もありません。このオープンテストは、正式にアプリをリリースするまでの重要なマイルストーンです。アプリを実際の車ですべてのユーザーに使ってもらうことに一歩近づきますので、ぜひ Android for Cars App Library を使い、Play Console でオープン テストトラックを選択してアプリを公開してください。
Android Auto アプリに関する今後の予定についてお知らせします。
現在、このライブラリを Android Jetpack に追加する作業を進めています。これにより、他の Jetpack API との整合性が向上し、新機能が見つけやすくなります。Jetpack ライブラリが利用できるようになると、既存のライブラリからのアプリ移行が簡単になり、名前空間を変更していくつかの API 呼び出しを調整するだけの作業で完了します。Jetpack でライブラリを安定させた後は、その新しいアプリを Google Play ストアの本番環境トラックに公開できるように準備を進めればよいのです。
Jetpack ライブラリを待たずとも、オープン テストトラックに公開することはできるようになっています。以下の手順で公開してみましょう。
多くのデベロッパーの皆さんが開発した自動車向けアプリを、実車でテストすることを楽しみにしています。
アプリでアクション ボタンが提供されていない場合、URL を共有するデフォルトのアクション ボタンがトップバーに追加される
CustomTabsIntent.Builder
setShareState()
val customTabsIntent = CustomTabsIntent.Builder()
.setShareState(CustomTabsIntent.SHARE_STATE_OFF)
.build();
addDefaultShareMenuItem()
setDefaultShareMenuItemEnabled()
プライバシー サンドボックスの取り組みは、一連のプライバシー保護 API を提案することで、サードパーティ Cookie などのトラッキング メカニズムのないオープンウェブに貢献するビジネスモデルをサポートします。この取り組みは 2019 年に始まり、Chrome では昨年の 1 月と 10 月に最新の進捗状況を共有しました。
1 年間のインキュベーション期間を経た 2021 年はテストの 1 年間となり、ウェブのエコシステムが関与する機会が継続的に発生するでしょう。この投稿では、Privacy Sandbox API とその提案の状況について、最新情報をお届けします。
サイト運営者や広告主は、広告を含め、関連性が高くユーザーが興味を持つコンテンツを提供したいと考えています。現在のウェブでは、どのようなサイトやページにアクセスしたかを観察することでユーザーの興味を測ることが多く、これにはサードパーティ Cookie やデバイスのフィンガープリンティングなど、透過性が低く好ましくない仕組みが使われます。
3 月の Chrome リリース 89 で、Federated Learning of Cohorts API（FLoC）のオリジン トライアルを開始する予定です。FLoC は、同じような閲覧パターンを持つ人々を大きな集団に分類し、「大勢」の中の個人やブラウザの閲覧履歴を隠すことで、関連性の高いコンテンツや広告をユーザーに届ける新しい仕組みを提案します。現在 Google 広告は、FLoC アルゴリズムのテストから得た最新情報を共有しています。このテストによって、関連性の高い興味ベースの広告を提供するという点で、提案された API がサードパーティ Cookie と同様の効果を持つ可能性があることが示されました。
標準化コミュニティで盛んな議論を呼んだユースケースの 1 つが、どうすれば企業はオーディエンスを形成できるか、そしてどうすれば再マーケティングによって以前のユーザーをウェブサイトに呼び戻せるか、ということでした。昨年には、このユースケースに対応しつつ、他の提案と同じプライバシー保護を提供できる TURTLEDOVE が Chrome に導入されました。ウェブサイトは、入札や広告表示に関する情報を含む Interest Group を保存するようブラウザに依頼します。そして、この Interest Group に基づいて広告購入候補者によるオンデバイス入札が行われることになります。
Chrome の新しい FLEDGE（First "Locally-Executed Decision over Groups" Experiment）提案は、寄せられた多くの提案に含まれる新しいコンセプトを組み込んで TURTLEDOVE を拡張したものです。FLEDGE には、オンデバイス入札アルゴリズムで追加情報を利用する仕組みが含まれています。この追加情報は、この目的に限定して設計された、新しい信頼できるサーバーから提供されます。新しい信頼できるサーバーが利用できるようになる前に初期段階の実験をサポートするため、私たちは "Bring Your Own Server" モデルを提案しています。また、この最初の実験は、2021 年中に行いたいと考えています。
マーケティング担当者が広告キャンペーンを行う場合、各広告を見たユーザー数と、それによって購入や登録などの行動に結びついたのかを理解することが重要です。
2020 年 9 月に、パブリック Chrome オリジン トライアルでテストを行うために、Event Conversion Measurement API を公開しました。これを使うと、マーケティング担当者はサードパーティ Cookie を使わずにコンバージョンを測定できます。ブラウザは、クリックとコンバージョンを記録し、匿名レポートを共有します。このテクノロジーは、将来的に「ビュースルー コンバージョン」（ユーザーが広告を見た後、時間をおいて行動する場合）もサポートする予定です。
マーケティング担当者が特定の広告キャンペーンの対象範囲を理解できるように、2020 年 4 月に Aggregate Measurement API を公開しました。この API は、複数のサイトにわたってユニーク ユーザーが広告を見た回数を測定する場合に役立ちます。ここでも、個人の特定に利用される可能性があるデータが公開されることはありません。この仕組みは、ある集計しきい値を超えた場合に一度だけデータを報告することで実現します。Aggregate Measurement API は、今年の前半に公開してパブリック オリジン トライアルとしてテストすることを計画しています。
サイトやサイト運営者は、実際のユーザーと、スパム作成者や詐欺師、ボットを確実に見分けられなければなりません。昨年 7 月には、Trust Tokens API をテスト用に公開しました。この機能は、詐欺に対抗するため、ユーザーの身元を特定することなくユーザーの正当性を評価します。Chrome 89 では、新しいタイプの Trust Token 発行者をサポートするために、オリジン トライアルを導入します。これにより、ユーザーのプライバシーを守りつつ、モバイル デバイスによる詐欺の検出機能を向上させることができます。
2020 年には、現在のウェブ テクノロジーの安全性も向上しました。Chrome と Edge が SameSite Cookie ポリシーを採用し、近日中に Firefox も採用する予定です。このポリシーにより、デベロッパーがサイト間アクセスを必要とすることを明示しない限り、Cookie はファーストパーティとして扱われます。これは Android の Webview にも導入されており、Android S 以降をターゲットとしたアプリでは、"SameSite=Lax" がデフォルトの扱いとなる予定です。
今月の Chrome 88 リリースの新機能として、このポリシーを強化します。具体的には、接続の安全性のダウングレードを含むいくつかの形態のクロスサイト攻撃を防ぐため、SameSite の定義を変更します。これにより、同じホストのドメインの安全なバージョンと安全でないバージョン（https://site.example と http://site.example など）は、お互いにサードパーティと見なされるようになります。
実際のウェブサイトが複数のドメインや国コードドメイン（.com、co.uk、.de など）にまたがる場合があることは認識しています。Chrome 89 では、オリジン トライアルとして First Party Sets を導入する予定です。これにより、ドメイン所有者は関連するウェブドメインのグループが同じ組織に所属するものであることを明示的に宣言できるようになります。この宣言を行うと、対象のドメインはお互いに「同じパーティ」として扱われます。そのため、たとえばショッピング サイトが複数のドメインをまたぐ場合でも、ユーザーはログイン状態を維持できるようになります。トライアルへの登録はこちらから行ってください。
さらに、既存の迷惑なトラッキング技術を防ぎ、問題にならない回避策を提供するため、Chrome の変更も進めています。
今後数週間のうちに、新しい User-Agent Client Hints（UA-CH）API の Chrome 安定版ロールアウトを終える予定です。これは、デフォルトでユーザーのブラウザに関する情報をすべて取得するのではなく、デベロッパーが特定の情報をリクエストできるようにするものです。将来的に Chrome は従来の User-Agent 文字列で提供する情報を制限する予定なので、デベロッパーには UA-CH API への移行を始めることを推奨します。現在の User-Agent 情報は、フィンガープリンティングに使われる可能性があります。
先週、Gnatcatcher を導入しました。これは、ユーザーのグループが同じプライベート化サーバーを通してトラフィックを送信できるようにする提案で、サイトのホストから IP アドレスを効果的に隠蔽します。また、Gnatcatcher は、不正利用の防止などの正当な目的で IP アドレスへのアクセスが必要なサイトには、認証や監査を行った上で、アクセスを保証します。
昨年 10 月にお知らせしたように、ユーザーがキャッシュの仕組みを使ってアクセスしたサイトを別のサイトから確認できる機能は、近日中にクローズする予定です。これによって元のリクエストを行ったサイトのみがキャッシュされたリソースにアクセスできることが保証され、クロスサイト トラッキングや検索攻撃などのセキュリティ攻撃のリスクを減らすことができます。この変更は、3 月の Chrome 89 からすべての Chrome ユーザーにロールアウトされる予定です。
biddingFunctions
BidRequest
Floc
User
message Floc { // The value of a cohort ID – a string identifier that is common to a large // cohort of users with similar browsing habits. optional string id = 1; // The type of the FLoC. See // https://github.com/google/ads-privacy/blob/master/proposals/FLoC/FLOC-Whitepaper-Google.pdf. enum FlocType { // Default value that should not be used. FLOC_TYPE_UNKNOWN = 0; // FLoC simulated using affinity hierarchical clustering with centroids // and feature extraction based on Topic categories as described in the // whitepaper. SIMULATED_AFFINITY_CLUSTERING_CENTROID_VERTICAL = 2; // FLoC simulated using SortingLSH clustering algorithm and Domain One-hot // encoding feature extraction as described in the whitepaper. SIMULATED_SIMHASH_SORTING_LSH_DOMAIN_ONE_HOT = 3; // FLoC simulated using a k Random Centers locality-sensitive hash // function as described in // https://github.com/google/ads-privacy/blob/master/proposals/FLoC/k-random-centers.md // with Domain TF-IDF feature extraction as described in the whitepaper. KCENTER_DOM_FILTERED_TFDIF = 4; } optional FlocType type = 2; }
google_user_id
hosted_match_data
FlocType
BidResponse
FrequencyCap
Bid
message FrequencyCap { // An ID that can represent a bidder's use-case for frequency capping; for // example, it could represent their campaign, ad, line item, etc. It should // not contain any user-specific information or identifiers. optional string fcap_id = 1; // The time units for which frequency caps can be enforced. enum TimeUnit { UNKNOWN_TIME_UNIT = 0; MINUTE = 1; DAY = 2; WEEK = 3; MONTH = 4; // When INDEFINITE is used, time_range will be ignored. INDEFINITE means // the frequency cap will be applied for a long period of time, (longer // than a month) but not necessarily forever. INDEFINITE = 5; } // The unit of time used to specify the time window for which a frequency // cap applies. optional TimeUnit time_unit = 2; // The length of the time window, in units specified by time_unit, for which // the frequency cap applies. For instance, if time_unit=WEEK and // time_range=3, then capping is applied for a three week period. If the // time_unit=INDEFINITE, this will be ignored. optional int32 time_range = 3 [default = 1]; // The maximum number of impressions allowed to be shown to a user for // the provided frequency_cap_id within the time window described by // time_unit and time_range. optional int32 max_imp = 4; }
