遷移クリックの問題：いくつのレミングがdrれていますか？

AdRiverの同僚とコミュニケーションをとると、広告のすべてのクリックがターゲットサイトのクリックになるわけではないことが判明しました。 訪問者の5〜10％が失われていると聞くのは普通のことです（一般的な測定エラーの枠組み内で非常に自然な数字）。 しかし、結局のところ、損失は最大50％になる可能性があります。 そして、リークが発生する場所、通常の健全な適切なクリックが遷移にならない理由をより詳細に理解することにしました。

障害1：この海岸に

ほとんどの場合、広告主のサイトからサードパーティのサイトにアクセスする前に、クリックアカウンティングページへのアクセスは平均的なユーザーには見えません。 このページは、広告への遷移をキャプチャし、ユーザーをさらに送信（リダイレクト）することを除いて、何も行いません。 すべての広告ネットワークでも、この動作は関連しています。クリックスルー（CPC）またはアクション（CPA）が追跡されている場合にのみ、各ユーザーのアクションを厳密にカウントする必要があります。 ただし、CPMで販売される広告（1000インプレッションあたりの固定費用）も同様に考慮されます。広告主のサイト（広告が表示され、クリックが発生する場所）とターゲットサイト（ユーザーがアクセスする必要がある）、ユーザーが広告サーバーにアクセスする、これは単に呼び出し（クリック）の事実を考慮するために必要であり、その後、ユーザーの訪問に関する情報を使用して分析レポートを作成します。



この障害はクリックの損失には影響しません。クリックの固定とターゲットサイトへの移行の間にユーザー側で不要なアクションはありません。 ただし、特定の条件下では、この手順（特に1つのリダイレクトではなく複数のリダイレクト）がかなりの時間（1秒以上）を要する場合があり、次の手順で損失が増加します。 実際、ユーザーはブラウザにリダイレクトを白い画面で表示し、N秒待機した後にターゲットサイトが表示されるかどうかを知りません。



できること： JavaScriptを介してユーザーのアクションを考慮することができる場合（これを行うことができるユーザーの統計サーバーに非表示ピクセルを送信する）、これはあなたがする必要があることです。 さらに、統計サーバーのDNSクエリを0に減らす必要があります（通常、リダイレクトの待機時間の大部分がかかります）。これを行うには、広告を読み込むときに（または同じドメインから広告を読み込むときに、このドメインから透明ピクセルを呼び出します。遷移をカウントします）：ブラウザはサイトに対して通常のリクエストを行い、DNSレスポンスをキャッシュし、近い将来それを使用できるようになります。 そしてもちろん、統計アカウンティングサーバーと広告配信サーバーの両方の可用性とパフォーマンスを24時間監視する必要があります。これには、応答時間が最小値（10〜20ミリ秒）を超えないようにすることも含まれます。



損失：クリックの最大1.5％。ほとんどの場合、これらは不適切な訪問です。 これらの損失は、発生した場合、広告ネットワークによって記録されません（クリックの事実が記録される前でも発生するため）。

障害2：ローカルアクセス不能

すべてのトラブルと損失が相殺しようとしている最も有名な問題。 サイトとユーザーの両方がインターネット上にある場合、特定のユーザーと特定のサイトの接続が常に発生するとは限らないという事実に関連しています。 サイトとユーザーの両方がモスクワにいる場合、状況はほぼ安定しており、損失は通常0.001％以下です。 しかし、このサイトがヨーロッパのどこかにあり（現在人気のあるドイツのサイト）、ユーザーがウラルを越えて位置している場合、損失はそれほど少なくなく、クリックの3％に達する可能性があります。



これには、Webリソースのネットワークアクセシビリティの問題だけでなく、これらの問題を悪化させる可能性のあるサーバーからの長い応答時間の問題も含まれる必要があります（そして、ユーザーにとって、ブラウザがサイトを開けなかった理由はありません：パッケージが失われました）外出中またはブラウザがサーバーからの応答を待たなかった）。 最大200ミリ秒のサーバー応答時間は正常と見なされます（すべてのネットワーク遅延を考慮すると、ユーザーがロシア全土にいる場合、サーバーは厳密にモスクワにあり、ページを100ミリ秒以内に返す必要があります）：この場合、ユーザーはサーバーに問題があります気づかないでしょう。 大きなリソースの場合でも、最大1％のユーザーはサーバーからの応答を待つ時間がありません（一般的な状況は、モバイルユーザーの途中でベースステーションが変更されるときであり、サーバーからの応答が十分に速く到着しなかった場合は、再度要求を送信する必要があります）。



そしてもちろん、トラフィックやサーバーの問題のために、サイト自体も物理的に利用できない場合があります（ loadimpact.comでサイトのフォールトトレランスを確認してください ）。 ただし、通常、このような問題の割合（高品質で信頼性の高いサイトの場合）は小さく、最大0.1％です。



できること：ターゲットユーザーをサイトに接続する際の問題を診断する必要があります。 これは、複数のポイントから可用性を監視することで実行できます（複数の監視サービスを使用して範囲を最大化することをお勧めします）。 次に、サイトを別のホスティングサイトに移動するか（アクセシビリティに関する問題が大幅に少なくなります）、または広告予算から一定数の損失を直ちに相殺する必要があります。これらのユーザーはサイトにアクセスできません。



損失：クリックの1〜10％。

障害3：途中

次のカテゴリの障害について聞いたことがあるかもしれませんが、そのようなことは考えていません。ポケットからお金を盗む泥棒です。 これは、サイトにアクセスしたユーザーのブラウザの白い画面です。 これは遅いサイトの典型的な問題であり、非常に典型的な方法でも解決されます：データ圧縮、スタイルファイルとその最小化の組み合わせ、ページの終わりへのクライアントロジック（JavaScript）の転送、またはページの先頭での読み込みが必要な場合の最大限の緩和 WEBO Softwareによるオンラインストアの速度の調査によると、現在、ほとんどのユーザーにとって人気のあるサイトのホワイトスクリーンステージは1.5秒以下です。 これは良い値であり、大部分のユーザーがサイトにアクセスすることを保証します（クリックすると遷移に切り替わります）が、ユーザーに接続の問題（地域、モバイルインターネット）がある場合、待機時間が大幅に増加します。



最も興味深いのは、実際には、すべてのカウンターがサイトの読み込みのこの段階でユーザーの失敗を記録しないことです。カウンター自体は何かをカウントするためにまだ読み込まれていません。



できること：最大クライアント最適化方法（FEO）を適用してサイトを高速化し、5 Mbps接続でのホワイトスクリーン時間（DOMreadyイベントの前）を1〜1.5秒に短縮します-www.webpagetest.orgを使用して結果を確認できます。



損失：クリックの2〜10％。 ほとんどの場合、これらは不適切な訪問です。ユーザーは、ターゲットサイトへの移行が記録される前にブラウザを閉じることができます。

障害4：ほぼ帆走

ここでの問題は、カウンターの距離（ページのロード中）とデータの送信時間です。 ページ全体のロードが数秒（10秒）になる可能性がある場合、ユーザーは単純にカウンターを待たずにページを閉じる（またはリンクをたどる）ことができます。 損失が発生する場所です。 概して、この段階での損失は、誰もが削減しようとしているのと同じ障害率を特徴づけます（ただし、記事からわかるように、これはサイトの可用性に関する実際の問題の氷山の一角にすぎません）。 当然、サイトが加速されると、速度（サイトのページの読み込み時間）のみに関連する直帰率が低下します。 直帰率の実際の低下は2-10％のレベルで可能です（サイトが大幅に高速になり、ユーザーが既にサイトに留まる傾向がある場合、つまりサイトの速度がユーザーのこのサイトへの訪問の決定に影響を与えなくなる場合）。



遅いサイト（グラフィックスやインタラクティブな要素でオーバーロードされている）の場合、速度に関連するかなりの数の失敗が常にあります。 しかし、有能なアプローチを使用すると、このような障害の最大80％を排除できます。



できること：テキスト情報の圧縮と画像の最適化から、二次情報ブロック（ウィジェット）の遅延読み込みまで、クライアント最適化の既知のすべての手法を適用します。 「重い」サイトの場合、ユーザーを切り替えるために使用できる（たとえば、動的に-追加のリダイレクトなしで白い画面の段階で）「ライト」バージョン（地域ユーザーまたはモバイルユーザー向け）を開発し、それによって失敗率を最小限に抑えることは理にかなっています。 タスクは、ページ全体の読み込み時間（onload）の値を最小化することです。 今回は、サイトの速度がGoogleアナリティクスを示し、Googleウェブマスターを考慮しているため、前の段落（ www.webpagetest.org）で指定されたサービスを測定に使用できます。



損失：クリックの3〜20％。

障害5：ホリネズミはいましたか？

クリック損失が発生する理由を議論する際に使用することを好むもう1つのよく知られた問題：これらのカウンター間の不一致。 単一の統計システムを使用してクリックとクリックの両方をカウントする場合でも、わずかな偏差が発生する可能性があります（収集されたデータの同期外れ、アカウンティングエラー）。 異なるシステムを使用してクリックを追跡し、サイトへのクリックを追跡する場合、差異はさらに大きくなる可能性があります。 私たちの経験では、異なるカウンターのデータ間の不一致は最大20％です。 なぜこれが起こっているのですか？



カウンターは異なるジオベース（IPアドレスと都市/国の異なる対応）を使用します。 これは、ロシアからのユーザーが他の国からのユーザーとしてカウントされるという事実につながります。 またはその逆：ロシアのIPアドレスは外国人ユーザーによって使用されます。 ロシアの都市のジオベースの状態は特に嘆かわしく、精度は約80％です。 カウンタは、さまざまなニュアンスを持つさまざまなユーザーアカウンティングスキームも使用します。Cookieの設定方法（JavaScriptを介した同じドメインから、またはHTTPヘッダーを介したサードパーティから）。 1つのIPを持つユーザー（企業ユーザー）がどのように考慮されるか-ブラウザーごと、Cookieごと。 ユーザーデバイス（特にモバイルデバイス）がCookieを受け入れる方法（設定、設定しない）。



対処方法：単一のカウンター（ベース）を使用して、クリックとクリックの両方を考慮します。 これにより、潜在的な不一致が最小限に抑えられます。



損失：クリックの1〜10％。

おわりに

ご覧のとおり、全体的には一見取るに足りない微妙な問題が、インターネット上の広告キャンペーンの有効性の大幅な低下につながる可能性があります（さまざまな理由で最大50％の広告予算の損失）。 広告キャンペーンを開始する（またはユーザーを引き付けるために新しいチャネルを接続する）前に、サイトを読み込むすべての手順を監査し、重大な問題がないことを確認する必要があります。