作業前に知っておくべきAMPの特徴
AMPの大きな特徴は、パフォーマンス改善とGoogleの検索結果に優遇表示です。しかし、マーケティング面、実業務面を考慮すると他にも特徴があります。
1.非AMPページのPVは落ちる
AMP実装を行うと、検索結果がすべてGoogle AMP Viewerで表示されます。その為「No Standalone AMP」で実装している場合、Google検索結果から非AMPページへのアクセス経路がなくなります。
つまり、非AMPページへのアクセスが下がり、かわりにAMPページのアクセスが増えるようになります。
2.PVと共にセッションやユーザー数も増加する
AMPページと非AMPページ間でGoogle AnalyticsのクライアントIDが保持できない問題があります。そのため、2017年5月現在はセッション数やユーザー数が増加してしまう特徴があります。
対応案
（1）AMPページのみ別プロパティで計測することで、集計時の混乱を最小限に防ぐ。
- GoogleのAnalytics Blogで推奨されている方法。
- 「No Standalone AMP」では問題はありませんが、「Standalone AMP」で実装した場合はすべてのViewが1つのAMPページになるので対応困難。
（2）クライアントIDやUserIDをサーバーサイドで管理して適応する。
- 参考：『GoogleアナリティクスのAMP対応を利用する際に注意すべきたった1つのこと』（datalove’s diary）。
- 参考：『Cookieとユーザーの識別』（Web向けアナリティクス（analytics.js））。サーバーサイドの開発負担が大きい。
（3）カスタム キャンペーン パラメータを設定し、計測時にフィルタリングをする。
- 参考：『AMPページ⇒AMP以外のページに移動したときのAnalyticsでの計測』。効果測定時の運用工数が増加する。
対応方針
この件を問題と捉えるか、特徴と捉えるか、で対応方法は変わってきます。効果測定を行う担当者の方と相談して方針を決めて貰えればと思います。
| 方針 | 対応 |
|---|---|
| Google AMP Viewerで開いたAMPページと非AMPページは同一セッションとして扱う。 | （2）の対応が必要。 |
| Google AMP Viewerで開いたAMPページは別のブラウザ、別アプリで表示しているものと同等として扱い、別セッションとする。 | （3）の対応が必要。必要であれば（1）も対応する。 |
3.平均PVが落ち、直帰率が上がる可能性あり
こちらは賛否両論があり、参考になるデータも少ない状況です。
Google AMP Viewerはブラウザ上でスワイプを行うと、別サービスのAMPページを表示できます。スワイプ1つで離脱ができてしまうのでサイト内の回遊率が落ちる可能性が想定できます。もちろん、ユーザーの傾向やUI、UXによっては、危惧しているような問題が起きない可能性も十分あります。また、「2.PVと共にセッションやユーザー数も増加する」の件もあるので、計測時に意識する必要性があります。
4.実装できるUIに制限がかかる
AMP HTMLは通常のHTMLよりも実装方法に制限がかかっています。
- CSSはインラインで記載。記載可能なのは50KBまで。
- 「cdn.ampproject.org」で配布されているJavaScript以外は利用できない。つまり、自分で書いたJavaScriptは利用できない。
- img, video, audio, iframe、form, inputは、代わりにamp-****などのカスタムエレメンツを使う。
上記の制限があるため、デザイン作業時に下記の課題が発生します。
- CSSを過度に使ったデザインは実装できない。容量制限があるため。
- JavaScriptを使った自由なインタラクションは実装できない。
- JavaScriptを使用したインタラクションを行いたい場合は、提供されているコンポーネントを利用しなければならない（カスタマイズに限界あり）。
5.広告効果に影響がでる
「No Standalone AMP」実装の場合、非AMPページ（ブラウザ表示用のページ）とAMPページで下記のような差異が生じます。
- 「3.平均PVが落ち、直帰率が上がる可能性あり」による離脱の問題。
- 「4.実装できるUIに制限がかかる」によるUIの変化。
- 非AMPページのように自由に広告を設定できない。
3.について説明すると、
- AMPに対応しているベンダーの広告以外は利用できません（大手は対応済みなので基本は問題ないと思います）。
- AMPでサポートしていない広告は、amp-iframeを使って実装できます。ただし、画面の上部（Viewportの上端から75％の位置）には配置できません。
- AMPでは自分で書いたJavaScriptが利用できないため、インタラクティブな広告は実装できません。
そのため、非AMPページとAMPページで広告効果が変わってしまう可能性があります。広告効果が上がる可能性もあれば、下がる可能性もあります。
A4Aについて
Googleは2017年1月6日に「A4A（amp for ads）」と呼ばれる高速でAdが表示できる仕様を公開しました。A4Aはベンダー側に提供されている仕様なのでAMP側では従来の「amp-ad」を使えばよいです。ベンダー側がA4A対応を行ったタイミングで広告表示が高速化されます。ネックとなっている広告のパフォーマンスを改善することで、AMPのパフォーマンス改善とそれに伴うCV率の改善を図っている模様です。
- 『Google、AMPに完全対応した爆速表示の広告 A4A を公開』（海外SEO情報ブログ）
- 『But what about the ads?』（Accelerated Mobile Pages Project）
- 『ampproject／amphtml』（GitHub）
6. フロントエンドの開発
AMP HTMLは実務かつ、分業制で制作を行っている場合、慣れるまで時間がかかります。逆に、個人でデザインとマークアップする場合は、それほど工数はかかりません。
HTML
- 通常のHTMLと少し実装仕様が異なるので、初回の学習コストはかかります。
- リリース前にデバッグツールを使った確認が必要。
- リリース後に正常にGoogleに認識されているかの確認が必要。
CSSの50kb制限があるため、設計方法を一新する必要性がある
- Selector名の短縮が必要。
- 頻繁につかうbackground-imageなどのpropertyは共通化する（Sass利用の場合は@extendがおすすめです）。
- 利用するUIコンポーネントの数の調整。
各チームのコミュニケーションコスト
- 上記に伴う企画者との仕様の調整。
- 上記に伴うデザイナーとの仕様の調整。
