パスワードはオンライン情報の保護に役立ちます。パスワードを安全に保つことが何よりも重要なのはそのためです。しかし、ショッピングやエンターテイメントから個人の金融取引まで、さまざまなウェブサイトで数十個（場合によっては数百個）のパスワードを扱うとなれば、常に新しいアカウントの設定や管理に追われているように感じます。もちろん、アカウントごとに強固で一意なパスワードを設定することがベスト プラクティスではありますが、それらすべてを記憶しておくのは難しいことかもしれません。そこで、皆さんをサポートするため、Chrome にパスワード マネージャーを設けています。
スマートフォンやコンピュータ、タブレットでウェブをブラウズするとき、Chrome なら、1 クリックでパスワードを作成、記憶、自動入力できます。サイトにログインした後、パスワードが侵害されていた場合は警告が表示されます。また、Chrome の設定から常に自分でチェックすることもできます。そして、うれしいお知らせがあります。新しいアップデートにより、パスワードをさらに細かく管理できるようになりました。
脆弱なパスワードを簡単に修正
皆さんもきっと、急いで新しいログインを設定したくて、単純な「ペットの名前」のようなパスワードを設定してしまったことがあるはずです。しかし、脆弱なパスワードはセキュリティのリスクとなるので、避けるべきです。Chrome 88 では、シンプルなチェックで脆弱なパスワードを見つけて、簡単に対応できるようになります。
パスワードをチェックするには、プロフィール画像の下にある鍵アイコンをクリックするか、アドレスバーに chrome://settings/passwords と入力する
Chrome には、ウェブサイトにログインする際に保存済みのパスワードの更新を促す機能がすでに組み込まれています。しかし、1 か所で複数のユーザー名とパスワードを簡単にアップデートできれば便利だと思う方もいるでしょう。そこで、PC 版と iOS 版の Chrome 88 より、Chrome の設定からすべてのパスワードをすばやく簡単に管理できるようにします（Chrome の Android アプリも近日中に対応予定）。
2020 年の改善に続いて
今回の新たなアップデートは、昨年行われたたくさんの改善が土台になっており、そのすべてが、オンラインの安全性を向上させ、ウェブのブラウズをさらに簡単にするために貢献しています。
パスワードを安全に保つため、ぜひ新しいアップデートを利用しましょう。2021 年もすばらしいパスワード機能が登場する予定なので、ご期待ください。
AMP コミュニティから特に多く寄せられている要望の 1 つは、高パフォーマンスな AMP コンポーネントを AMP 以外のページでも利用できるようにすることです。AMP Project はこの要望に対処するため、2 年にわたって Bento AMP と呼ばれる取り組みを懸命に進めてきました。その具体的な目的は、完全な AMP ランタイムを使わなくても、AMP コンポーネントがもたらすパフォーマンスとユーザー エクスペリエンスのメリットを活用できるようにすることです。今日のデベロッパー プレビューのリリースにより、その実現に向けて 1 歩前進したことをお知らせします。Bento コンポーネントを試してみたい方は、スタートガイドをご覧ください。
AMP Project の目的は、常にユーザー ファーストな体験を作れるようにデベロッパーをサポートすることにあります。この価値提案の中核にあるのは、高パフォーマンスでユーザー中心の AMP コンポーネントです。今回、Bento AMP によって、必要な場所で AMP コンポーネントを使えるようになります。お気に入りのフレームワークや CMS と AMP コンポーネントを組み合わせることができるのです。
たとえば、カルーセルを AMP 以外のページに追加する、有効な AMP を作成する過程で AMP コンポーネントをテストするなど、1 回限りのケースで Bento コンポーネントを使うことができます。Bento AMP プロジェクトの最新の進捗状況は、GitHub のワーキング グループで確認できます。または、AMP の次の展開をご覧ください。
現在のリリースは、いくつかのスタンドアロン AMP コンポーネントのデベロッパー プレビューです。その目的は、今回の実装の技術的な成否に関するフィードバックを集めることです。現在の Bento AMP コンポーネントにはまだ AMP ランタイムが必要ですが、コンポーネントはページが「有効な AMP」でなくても動作します。つまり、ページにスタンドアロン AMP コンポーネントをインポートし、必要に応じて他のカスタム JavaScript と連携できます。
始めるにあたっては、まずこちらのガイドをお読みください。今回のデベロッパー プレビューの期間中は、以下の Bento コンポーネントを試験運用版として利用できます。
なお、これはデベロッパー プレビューなので、AMP ページで Bento コンポーネントを利用すると、ページは有効でなくなります。この点は、正式版をリリースする際には対応したいと考えています。デベロッパーの皆さんからフィードバックを集めるため、これら最初の Bento AMP コンポーネントを提供できるのはうれしいことですが、Bento コンポーネントのデベロッパー プレビュー期間中に AMP エクスペリエンスをデプロイする場合は、最新の本番バージョンの AMP コンポーネントを使って有効な AMP ページを作成することをお勧めします。
将来的には、完全版をリリースして Bento コンポーネントをすべての HTML ドキュメントで利用できるようにする予定です。それにより、高パフォーマンスなコンポーネントを使ってすばらしいページ エクスペリエンスを作成できるようになります。そのための変更は今年中に行う予定なので、ご期待ください。
その次は、React バージョンの Bento コンポーネントを npm パッケージとして公開することも計画しています。これにより、React アプリが Bento AMP コンポーネントをさらに簡単に使えるようになります。
Bento AMP コンポーネントを試してみたい方は、スタートガイドをご覧ください。AMP チームは、GitHub や Slack チャンネルからフィードバックを送ることを推奨しています。フィードバックは大歓迎です。ぜひご協力ください。質問や問題がある方も、遠慮なくご連絡ください。
投稿者 : Naina Raisinghani（AMP Project、プロダクト マネージャー）
APP_AD
APP_ENGAGEMENT_AD
CALL_ONLY_AD
EXPANDED_DYNAMIC_SEARCH_AD
GMAIL_AD
HTML5_UPLOAD_AD
IMAGE_AD
LEGACY_APP_INSTALL_AD
LOCAL_AD
RESPONSIVE_DISPLAY_AD
RESPONSIVE_SEARCH_AD
VIDEO_RESPONSIVE_AD
AdGroupAdService.MutateAdGroupAds
AdService.MutateAds
PolicyValidationParameter.ignorable_policy_topics
PolicyValidationParameter.exempt_policy_violation_keys
GoogleAdsError.error_code
PolicyFindingErrors
GoogleAdsError.details
PolicyFindingDetails
PolicyViolationErrors
PolicyViolationDetails
AdGroupAdPolicySummary
AdGroupAd.policy_summary
EXPANDED_TEXT_AD
この記事は The AMP Blog の記事 "Correlation between Core Web Vitals and AMP" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
編集者のメモ : 以下の抜粋記事の出典は、Google のデータ サイエンティスト、Sixing Chen による HTTP Archive Blog への投稿です。より広い AMP コミュニティで共有するため、著者の許可を得た上で以下に転載します。詳細については、出典元のブログ投稿をご覧ください。
HTTP Archive Blog に掲載された最近の分析は、Core Web Vitals（CWV）とさまざまなウェブの特性との相関関係に着目しています。CWV はウェブ体験の質を表し、Google が特に重視する指標です。この調査では多くの技術を分析しており、因果関係を示唆するものではありませんが、AMP に関する結果は早い段階で AMP の大きな可能性を示しています。すなわち、AMP はユーザーにすばらしい体験を提供し続け、デベロッパーにとって費用対効果の高いソリューションとなる可能性をもっています。
この調査の目的は、「さまざまなウェブ開発の選択肢を評価する際の参考として、CWV とウェブの特性との関連性について理解を深めるために役立ててもらうこと」にあります。この調査では、HTTP Archive のデータを使用して、CWV といくつかのウェブ技術（JavaScript フレームワーク、JavaScript ライブラリ、CMS、UI フレームワーク、ウェブ フレームワーク、ウィジェットなど）との相関関係を分析しました。
AMP についての結果を以下に掲載します。斜体になっている部分は、すべて元の調査からの転載です。
ここでは、関連性についての結果を示すとともに、特に CWV への影響が大きいと思われる特徴的な点について記載します。
関連性についての結果を解釈するうえで重要な点があります。それは、特定のウェブ特性への正の影響と負の影響は、他のウェブ特性との比較においてのみ、また、多くのウェブ技術、多種多様なコンテンツ、さまざまなサードパーティ リクエストが混在したウェブサイトという前提でのみ解釈すべきであるという点です。たとえば、あるウェブ技術が強い正の影響を示していた場合、その技術は他の技術と比べてパフォーマンスが優れているようだと解釈すべきです。その技術をウェブサイトに導入すれば、ウェブのパフォーマンスが向上すると解釈することはできません。
LCP は数値の対数としてモデリングするので、高いほど悪いことになります。
%HSM 値が 1 に近い予測値は、数値 / カウントの特性値が高いことを示します。つまり、その技術の存在と高い LCP 値には強い関連性があります。%HSM が 0 に近い予測値では、その逆が成り立ちます（%HSM が高くなるほど悪化する）。
同様に、MSD が比較的大きな正の数である予測値は、数値 / カウントの特性値が高いことを示します。つまり、その技術が存在すると、LCP に強い負の影響を与えます。MSD が大きな負の数である予測値では、その逆が成り立ちます（MSD が大きな正の数になるほど悪化する）。
…
ほとんどの JavaScript フレームワークは LCP と強い正の相関を示すので、悪影響が生じることになりますが、AMP は例外です。特に影響が大きいのは、AngularJS、GSAP、MooTools、RequireJS です。
CLS は、与えられたしきい値を満たすかどうかを示すバイナリ インジケーターとしてモデリングします。1 はウェブサイトの CLS が 0.1 未満、0 はそれ以外であることを示します。そのため、1 は 0 より優れています。
%HSM 値が 1 に近い予測値は、数値 / カウントの特性値が高いことを示します。つまり、その技術の存在と CLS がしきい値を満たすことに強い関連性があります。%HSM が 0 に近い予測値では、その逆が成り立ちます（%HSM が低くなるほど悪化する）。
同様に、MSD が比較的大きな正の数である予測値は、数値 / カウントの特性値が高いことを示します。つまり、その技術が存在すると、CLS がしきい値を満たすことに強い正の影響を与えます。MSD が大きな負の数である予測値では、その逆が成り立ちます（MSD が大きな負の数になるほど悪化する）。
いくつかの JavaScript フレームワークは、CLS がしきい値を満たすことと強い負の相関を示すので、悪影響が生じることになります。ただし、AMP、GSAP、React では相関性と影響が低くなっています。AngularJS、Handlebars、Vuejs は特に負の影響が強いものでしょう。
AMP Project の目的は、常にユーザー ファーストな体験を作れるようにデベロッパーをサポートすることにあります。AMP Performance Working Group は、ウェブ上の AMP ページのパフォーマンスを継続的に管理し、定期的に AMP ライブラリのパフォーマンスを強化するアップデートをています。また、AMP は常に最新の状態を維持するライブラリなので、デベロッパーは何の追加作業も必要なく改善点を活用できます。AMP Project には、デベロッパーが簡単に Core Web Vitals のしきい値を満たせるようにするという役割があります。それを果たしている証拠として、上のような相関性についての調査結果を確認できることは私たちの喜びです。
Google 検索では、ランキングにおけるページ エクスペリエンス シグナルの利用がまもなくロールアウトされる予定です。それに向けて、AMP はウェブ パフォーマンスのベスト プラクティスの遵守に役立っており、すべての AMP ページが Core Web Vitals に準拠できるように最大限のチャンスを与えています。私たちは、そこまで到達できたことをうれしく思っています。以上のような理由から、デベロッパーの皆さんには AMP ページ エクスペリエンス ガイドの活用をお勧めしています。このガイドは、アクションにつながるアドバイスを AMP デベロッパーに提供し、AMP ページのページ エクスペリエンスの改善に役立つツールです。
いつものように、問題や機能リクエストがありましたらお知らせください。AMP ページ エクスペリエンス ガイドに関することは、特に遠慮なくご連絡ください。
customer.remarketing_setting.google_global_site_tag
GoogleAdsService.Search
GoogleAdsService.SearchStream
WHERE
QueryError.PROHIBITED_FIELD_IN_WHERE_CLAUSE
GoogleAdsFieldService.SearchGoogleAdsFields
google_global_site_tag
Google Play で配信しているゲームにおける定期購入の売り上げは 2019 年から急伸しています。定期購入を導入すると定期的な収益を確保する以外にも、ユーザーのエンゲージメントを高めることでゲームの世界観を広げ、ファンを増やす効果があることがわかりました。
日本の Google Play におけるゲームの定期購入売上成長率
では、定期購入の機能をうまく使いこなしているゲームタイトルはどのような部分を大事に考え、サービスの設計をしているのでしょうか。
ゲームに定期購入を導入する際には、まず解決したい課題を明確にすることが大切です。その上で、魅力的な定期購入の特典設計をし、ユーザーの購入意欲を喚起して継続してもらうための施策を講じます。
ゲームにおいて解決したい課題は、ゲームによって異なり、例えば以下のように多岐にわたります。
次に、設定した課題を解決するために定期購入をどのように組み入れ、どのような価値を提供するべきかを検討し、短期的な特典、中期的な特典、長期的な特典の 3 つを組み合わせたサービス設計を行います。
その他、解決したい課題が複数ある場合、条件や特典、期間などを変えた複数の定期購入を提供することも効果的です。KLab株式会社の「BLEACH Brave Souls」は、定期購入プランの「ブレソル満喫パス」と「キャラ獲得パス」を提供し、異なる目的に合わせて課題の解決を実現しています。それぞれのパスに短期、中期、長期（満 3 ヶ月継続）の特典を設定しており、また、両方のパスを同時に購入することも可能です。
単独の定期購入プランでもゲームを楽しめる設計になっていながら、組み合わせて利用することでさらにゲームプレイを充実できるようにすることで、ユーザーの満足度を下げない仕組みになっています。
ガンホー・オンライン・エンターテイメント株式会社が手掛けるパズルロールプレイングゲーム「パズル＆ドラゴンズ」は 2019 年 12 月に定期購入プランの「パズドラパス」を導入しました。「パズドラパス」では通常課金メニューとは異なる特典とサービス設計を意識しており、また、1 週間の無料トライアル期間を設けることで、加入意欲を高める施策を講じています。
株式会社スクウェア・エニックスが手掛ける「星のドラゴンクエスト」は、2019 年 7 月より定期購入プラン「星パス (月額版)」を提供しています。
14 日間限定シーズンパス「星の冒険者パスポート」の月額版として位置づけ、シーズンパスよりもより魅力的な特典を付与しています。また、こちらも初回の星パス (月額版) を無料で提供し、かつ、シーズンパスをすでに購入済みのユーザーにも無料で購入できるよう設計することで、定期購入プランの購入ハードルを下げました。
「モンパス」は、ロイヤルユーザーとのタッチポイントとなる機能を持った定期購入プランとして設計され、定期購入を継続しているユーザーに毎日、1 か月ごと、3 か月ごとと異なる特典を設けることで、継続意欲を上げ解約率を下げる効果を高めています。
定期購入ユーザーを増やすには、加入率と継続率を高め、解約率を削減することが必要です。また、定期購入を解約したユーザーへ再度の購入を促すことも重要です。定期購入プランの特典設計の他に、各社の定期購入は、加入率を向上する無料試用とお試し価格や、ユーザーの予期しない解約を防ぐ猶予期間、アカウントの一時停止機能などを活用しています。
上記 3 タイトルの定期購入ユーザーと非購入ユーザーと比べると、定期購入ユーザーのログイン率が高くなる、または、よりゲームをプレイする傾向があることがわかりました。
「パズル＆ドラゴンズ」と「星のドラゴンクエスト」では、定期購入ユーザーのログイン率が非購入ユーザーと比較して高くなりました。「パズル＆ドラゴンズ」の場合、「パズドラパス」を 3 か月継続購入しているユーザーと、非購入ユーザーを中央値で比較すると 30 ポイントほどログイン率が高く、同程度のゲーム進行度のユーザーのみ抽出した際にも、購入ユーザーは 20 ポイントほどログイン率が高くなりました。「星のドラゴンクエスト」の「星パス (月額版)」 購入ユーザーは、非購入ユーザーよりも、ログイン率が 1.2 倍高くなりました。
ログイン率が上がることで、ゲームプレイの継続率やクエストクリア回数の向上にも繋がります。「星のドラゴンクエスト」の「星パス (月額版)」 購入ユーザーは、非購入ユーザーと比べ、クエストクリア回数が 2.6 倍、マルチクリア回数は 3.2 倍になりました。「モンスターストライク」の「モンパス」を購入したユーザーは、モンパス購入前と比較して、一日あたりのプレイ回数が 20% ほど増え、エンゲージメント促進に寄与しています。
ゲームに定期購入を導入することで、ユーザー数やエンゲージメントを高め、ビジネスの成功につなげることができます。Google Play は、定期購入の価格設定オプションを簡単にコントロールしたり、定期購入の内容を変更するための複数のオプションが用意されています。詳しくはこちらをご覧ください。
Posted by Toru Shimazaki - Google Play, Partner Development Manager
ONLY_PARTER_SHOWN
LOWEST_UNIQUE
LOWEST_TIED
UNKNOWN
OfflineUserDataJobService.AddOfflineUserDataJobOperations()
AdWordsUserListService.mutateMembers()
userIdentifiers
membersList
TOO_MANY_USER_IDENTIFIERS
TOO_MANY
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; }
