プレースメント タグに含まれる URL に予約文字が使用されている場合、広告リクエストを渡そうとすると問題が生じることがあります。URL 文字列に使用されている予約文字の問題を防ぐために、URL エンコードの使用をおすすめします。
予約文字URL に含まれる特定の文字は、ブラウザにとって特別な意味を持ちます。たとえば、スラッシュ（/）は 1 つの URL を複数の部分に分割する文字、疑問符（?）は文字列の先頭を表す文字と解釈されます。これらの文字は、通常、予約文字と呼ばれます。これに該当しない、予約されていない文字（文字や数字など）には特別な意味はありません。URL 内で予約文字を使用する必要があり、ブラウザでそれらの文字が通常のように解釈されるのを防ぐには、URL エンコードが必要です。
URL エンコードを使用する必要がある状況として多いのは、クエリ文字列変数を使用しページ間でフォーム データを受け渡す状況です。たとえば、ユーザーがフォームに必要事項を記入して [送信] ボタンを押し、次のページに移動するとします。その URL のクエリ文字列内にはフォーム データが追加されます。しかし、ユーザーがフォームに記入するときには、予約文字（スペースなど URL でサポートされていない文字）を入力する可能性が常にあります。一般にウェブマスターは、フォームを処理する際に予約文字で問題が生じないように、2 段階のプロセスを行います。1 段階目では、ページを移動する前に入力内容をエンコードします。2 段階目では、ランディング ページで元の値を取得するためにクエリ変数をデコードします。
URL エンコードの使用が必要となるもう 1 つの例として、プレースメント タグにサイト提供のクリック文字列が含まれている場合があります。この場合、広告のランディング ページは実際には 3 つの異なる URL で構成されており、ブラウザによって最終的なランディング ページがリクエストされるまでに 2 回のリダイレクトが行われます。重要なのは、2 つ目と 3 つ目の URL（SSCS とランディング ページの URL）の両方が、最初のリクエスト（クリックをカウントするためのキャンペーン マネージャー 360 サーバーへのリクエスト）の URL に含まれるという点です。同様に、ランディング ページ URL は、サイト提供のクリック文字列を使用したリクエストに含まれます。これらの値にエンコード URL を使用していない場合、リクエストは適切に実行されない可能性があります。たとえば、2 番目と 3 番目の URL の両方に、クエリ文字列セクションの始まりを表す疑問符が含まれていたとします。このどちらの URL もエンコードされていない場合、ブラウザでは最初のリクエストと 2 番目のリクエストのどこでクエリ文字列が始まるのかを判別できません。
URL をエンコードする
予約文字の問題を回避するには、SSCS をエンコードする必要があります。また、SSCS を挿入する際、Key-Value に click= ではなく click1= を使用して、実際のランディング ページの URL をエンコードする必要もあります。
ツールを使ってエンコードすることもできます。そのための無料のウェブ アプリケーションをオンラインで利用できます。
