安心してください、間に合いますよ（GA4のAPIアクセスとランキング作成）

Google Analyticsがバージョンアップされ、Universal Analyticsが2023年6月をもって廃止、2023年7月1日からはGoogle Aanlytics 4に移行しないといけないというアナウンスが一年以上前からなされており、その期限が近づいてきました。何もしていない方は、次のような警告画面を見て「怖！」と怯えている方も多いでしょう。

めちゃくちゃ警告しています。

このGoogle Analyticsの設定自体は設定アシスタントで行うことができます。GtagやGoogle Tag Managerを利用している方はわりと自動的に移行作業が完了しますが、gaを利用している方は結構大変です。

Gtagを利用している方はこのセットアップツールでわりと簡単に移行できます。

さて、そんなわけで「移行」自体はそれほど難しい作業ではないのですが、WordPressカスタマイズあるあるとして「Google Analyticsのデータを用いてランキング」があります。WordPressの「人気記事」を作るプラグインはたくさんありますが、WordPress自体にデータを貯めるのは負荷が高い（DB書き込みを行うから）ので、Google Analyticsのデータを使うというのはよいアイデアですよね。

ただし、Google Analytics 4はUniversal Analyticsとは根本的にデータの持ち方が違う完全な別サービスであるようで、APIも変わっています。両者には互換性がありません。

• 旧API: Google Analytics Reporting API v4
• 新API: Google Analytics Data API(GA4)

両方ともバージョンに4が入っていてめちゃくちゃわかりづらいのですが、後者のAPIのみが今後も有効なものです。したがって、Reporting APIでランキングを作成する場合は、利用するライブラリを含めて書き換えないといけないのでした。

Taroskyでは複雑な要件のランキング作成を依頼されることが多かったので、自社のプラグインを持っております。それが ga-communicator というもの。今回はこちらをGA4に対応しました。特徴としては次の通りです。

• APIとの通信を主眼としており、主な機能は「認証周りの解決と関数の提供」です。一応、人気ランキングウィジェットがありますが、おまけです。
• サービスアカウントで利用できます。私も昔はOAuth認証などで実装してしまったことがありましたが、WordPressから使う場合は大抵サービスアカウントでなんとかなります。
• Googleの提供するPHPライブラリは異常な数のファイルサイズ（全サービスのデータ抽象化クラスが数万ある）が含まれており、これを入れるのが嫌なので、接続は独自関数を使っています。なので、軽いです。自動デプロイがこけたりしません。地味な自慢ポイントです。
• Taroskyのパートナーに使ってもらえるよう、Wikiを充実させました。
• composerとしても、WordPressプラグインとしても使えます。composerはテーマに同梱するようなケースを想定しています。プラグインとして利用する方はリリースからダウンロードしてください。

既存プラグインをリプレースできない場合

さて、プラグインを置換するような場合はそれでいいのですが、次のような場合はどうでしょうか。

• すでにカスタマイズしたプラグインを用意している。
• ランキング取得ロジックがやや複雑で、二度と触りたくない。
• キャッシュや取得データの保存などいろいろやってる。

こういう場合は新しいプラグインを導入するのはハードルが高いですよね。ga-communicatorは他のプラグインへの割り込みを想定して、No UI Modeというのを作りました。ga-communicatorは本来「サービスキーを保存する管理画面」「計測タグをレンダリングするための設定画面」などいろいろあるのですが、「そういうのはいらん」という方のために管理画面なしモードがあるわけですね。これを使うと、既存のプラグインの設定値（サービスキーなど）を利用して、API接続が可能になります。

// plugins_loadedフックより前、
// もしくはComposerで初期化するより前に定義すると管理画面なしモード
define( 'GA_COMMUNICATOR_NO_UI', true );
// スクリプトのレンダリングも停止したかったら以下の定数も定義
define( 'GA_COMMUNICATOR_NO_RENDERER', true );

Wikiにも書いてあるのですが、これだと設定値を利用できないのでフィルターフックを利用します。

// GA4のAPIに必要なサービスアカウントを返す（JSON形式の文字列）
add_filter( 'ga_communicator_predefined_key', function() {
	return get_option( 'my_service_key', true );
} );

// GA4のAPI利用に必要なデータをフィルターで設定する
add_filter( 'ga_communicator_predefined_option', function( $value, $key ) {
    switch ( $key ) {
        // プロパティID。
        case 'ga4-property':
            return '11110000'; // 決めうちの場合
        default:
            return $value;
    }
}, 10, 2 );

APIの利用に必要なものは以下の2つです。

1. サービスアカウントの鍵（JSON形式）
2. プロパティID（GA4の管理画面で取れます）

これで関数 ga_communicator_get_report_ga4() が動くようになるので、あとは既存の処理に割り込みするだけですね。

/**
 * ランキングを取得する関数
 */
function my_ranking() {
    // なんかいろいろやってる
    $response = my_ranking_fetch();
    // レスポンスをいろいろ処理する。
    return $rankings;
}

/**
 * APIと通信する関数
 */
function my_ranking_fetch() {
    // APIの切替フラグ。デプロイ後に必要なので、管理画面からできるとよい。
    $use_old_api = get_option( 'use_old_api' );
    if ( $user_old_api ) {
        // 以前の処理。
       return $rows;
    } else {
        return ga_communicator_get_report_ga4();
    }
}

ポイントは既存のプラグインがそもそも細かい粒度で分けられているかです。そこさえクリアできればサクッと解決できますね。今回、実際に何個か既存プラグインとの接続を行ったのですが、わりと簡単でした。そこで得た知見は次の通り。

• 「ランキングを生成する」という目的の関数だからといって、その中でダラダラ処理を記述しない。APIとの通信やキャッシュ、APIからのデータを処理してランキングにするなど、それぞれの処理は関数やクラスメソッドにわける。100行超えたら失敗。
• 一般的にAPIからのレスポンスは汎用的なデータ形式（配列とか）に一度変換する。そうしないと、今回のように「APIの取得先が変わる」という大きな変更の時にめんどくさい。Google_Service_AnalyticsReporting_ReportDataオブジェクトを返すのではなく、配列を返すべき。疎結合にする。

私は人の書いたプログラムを触ることが多いのですが、疎結合になっていて再利用性の高いコードを見ることは少ないので、その2点を心がけるだけでも相当なウデマエだと感じます。

では、この便利なプラグインを利用して、2023年7月を無事に迎えてください。