管理者専用

Indeedキャンペーン管理 運用マニュアル

毎週月曜のデータ取込・アラート運用・引き継ぎ手順

目次

  1. この作業の全体像とスケジュール
  2. 【毎週月曜】① Tableauからデータをダウンロード
  3. 【毎週月曜】② 取込画面へアップロード
  4. 【毎週月曜】③ 未分類のひも付け
  5. 【毎週月曜】④ 取込後の確認
  6. 【四半期ごと】アカウントマスタの更新
  7. Slackアラートの運用・点検
  8. 担当者の異動・入退社があったとき
  9. 困ったとき(トラブル対応)
  10. なぜこうなっているか(数値ルールの根拠)
  11. 引き継ぎ時に渡すもの一覧
  12. 週次チェックリスト(印刷用)

1この作業の全体像とスケジュール

Indeedのキャンペーンデータを定期的に取り込み、掲載終了アラートとダッシュボードを最新の状態に保つのが管理者の役割です。

作業のサイクル

頻度作業所要時間の目安
毎週月曜Tableauから6か月分をDL → 取込 → 未分類のひも付け → 確認15〜30分
四半期ごとアカウントマネジメントシートを取り込み、担当営業を最新化10分
随時担当者の異動・入退社があったときの通知先メンテナンス5分
毎朝(自動)Slackアラート送信(平日9時・人手不要)—

使うシステム

用途場所
データ取込https://kizuna-crm.pages.dev/indeed_import
結果の確認(ガント・一覧)https://kizuna-crm.pages.dev/indeed_campaign
DB操作・確認Supabase(SQL Editor)
通知先チャンネルSlack(#alert_solution / #alert_cs / #alert_area / #alert_other)
取込ができるのは管理者ロールのみです 現在の担当は大場です。引き継ぐ場合は、引き継ぎ先のユーザーが管理者ロールである必要があります。ロールは users テーブルで確認・変更します。
▲ 目次へ戻る

2【毎週月曜】① Tableauからデータをダウンロード

Indeedが提供するTableau上のレポートから、月間キャンペーンパフォーマンスを過去6か月分ダウンロードします。

アクセス方法

URLhttps://prod-apnortheast-a.online.tableau.com/
ユーザー名rshd_001.ag0007000.tableau@4191.co.jp
パスワード野沢または大場に問い合わせ(このマニュアルには記載しません)
表示名侑平野沢
アカウント管理者野沢侑平/大場久代
パスワード再発行Indeedの渉外担当に相談
パスワードの取り扱い このマニュアルは社内Webで閲覧できるため、パスワードは記載していません。必要な場合は野沢さんまたは大場に直接お問い合わせください。メールやSlackの公開チャンネルに貼らないでください。

目的のレポートまでの行き方

ログイン後、探索 → PROD → Campaign Performance Dashboard の順に開きます。

画面上部に 「Partner Campaign Performance Dashboard/パートナーキャンペーンパフォーマンスダッシュボード」 と表示されていれば正しい画面です。

ダウンロードの手順

  1. 画面右側の「対象年月」のプルダウンを開きます。
  2. 過去6か月分にチェックを入れます(例:7月に作業するなら 2026-02-01 〜 2026-07-01)。
    ※「(すべて)」は選ばないこと。データ量が多すぎて取り込みに時間がかかります。
  3. 下部の 適用 をクリックして反映させます。
  4. 画面右上のダウンロードアイコン(下向き矢印)をクリックします。
  5. 形式は 「クロス集計」 を選びます。
  6. ダウンロードを実行し、ファイルを保存します。
チェックする年月の考え方 当月を含めて6つ分を選びます。月が替わったら1つ増やして1つ外す、という形で毎月ずらしてください。
例:8月の作業なら 2026-03-01 〜 2026-08-01
画面上の日付表示について ダッシュボード上部に「表示可能なデータの最終日」と「最終更新日」が出ています。最終更新日を見れば、Indeed側のデータがいつ時点のものか確認できます。
▼ 記入欄:保存先フォルダの決まり(あれば記入してください)
 
必ずExcel形式のままにしてください 元データには結合セルが約8,000か所あります。CSVに変換すると結合セルの情報が失われ、正しく取り込めません。ファイルを開いて加工したり、CSVで保存し直したりしないでください。ダウンロードしたファイルをそのままアップロードします。
常に6か月分を取る理由 Indeedからは3か月分が縦に連結された形でDLされますが、取込の対象期間から外れた古い費用が欠けてしまう問題があるため、余裕をもって6か月分を取る運用にしています。毎回まるごと入れ直しても、データが二重に増えることはありません(第10章参照)。
▲ 目次へ戻る

3【毎週月曜】② 取込画面へアップロード

  1. https://kizuna-crm.pages.dev/indeed_import を開き、管理者アカウントでログインします。
  2. 上部のタブから 📥 キャンペーン取込 を選びます。
  3. ダウンロードしたExcelファイルを、画面の枠内にドラッグ&ドロップします。
  4. 解析する をクリックします。ファイルを読み込むだけで、まだ保存はされません。
  5. 画面に表示される件数を確認します(下記「確認するポイント」参照)。
  6. 問題なければ 取込実行 をクリックします。これで保存されます。

確認するポイント(解析後・取込実行の前)

表示される項目意味と見かた
元データの行数Excelの行数。6か月分で概ね14,000〜15,000行前後
重複排除後の件数キャンペーン単位にまとめた件数。6か月分で概ね9,000〜10,000件前後
新規/更新/スキップ新しく追加される数、上書きされる数、変更なしの数
未分類担当営業が特定できなかったもの。第4章で対応
件数が極端に違うときは中止してください いつもの半分以下、あるいは倍以上といった場合は、ダウンロードの期間指定が間違っている可能性があります。取込実行 を押さずに、Tableauからのダウンロードをやり直してください。解析しただけならデータは変わりません。
既知の不具合 取込の保存に失敗したとき、ボタンが押せないまま戻らないことがあります。その場合は画面を再読み込み(Ctrl+Shift+R)してやり直してください。修正予定の項目です。
▲ 目次へ戻る

4【毎週月曜】③ 未分類のひも付け

取込後、担当営業が特定できなかったキャンペーンが「未分類」として残ることがあります。放置すると、そのキャンペーンのSlack通知が #alert_other に流れ、担当者本人に届きません。

  1. 上部のタブから 🔗 未分類ひも付け を選びます。
  2. 一覧は費用の大きい順に並んでいます。上から順に対応すると効率的です。
  3. 各行で、正しい担当営業(または法人・顧客コード)を選んで保存します。
全部やらなくても構いません 費用が小さいものは影響も小さいので、上位のものから対応し、残りは翌週以降に回しても問題ありません。ただし件数が増え続けている場合は、アカウントマスタが古くなっているサインです(第6章の四半期更新を実施してください)。

ひも付けの仕組み(参考)

担当営業は次の順で自動判定されます。手動でのひも付けは、これでも決まらなかった分です。

  1. アカウントマネジメントシート(Employer IDの一致)… 約92%がここで決まります
  2. employer_kcode_map → gross_profits → hojin_master の順に照合
  3. それでも決まらないもの → 手動ひも付け
▲ 目次へ戻る

5【毎週月曜】④ 取込後の確認

取込が正しく反映されたか、画面とSQLで確認します。慣れれば2〜3分です。

画面で確認

  1. https://kizuna-crm.pages.dev/indeed_campaign を開きます。
  2. 担当を「全員」または「全グループ」にし、状態を「全て」にします。
  3. 右側の 「該当 ○件 / 全 ○件」 を見て、前週から極端に減っていないか確認します。
  4. 🔴 終了5日以内 のカードに、翌週分が入ってきているか確認します。

SQLで確認(Supabase SQL Editor)

取込ログを見る(直近5回)

-- いつ・何件取り込んだかの履歴
select imported_at, file_name, total_rows, dedup_rows,
       inserted, updated, skipped, imported_by
from indeed_import_logs
order by imported_at desc
limit 5;

データが二重に増えていないか確認

-- どちらも 0行 で返れば正常
select campaign_id, count(*)
from indeed_campaigns
group by campaign_id having count(*) > 1;

select campaign_id, target_month, count(*)
from indeed_campaign_monthly
group by campaign_id, target_month having count(*) > 1;

通知先が決まっていない担当がいないか確認

-- 0行なら全員カバー済み。名前が出たら第8章へ
select distinct m.sales_rep
from indeed_account_master m
left join indeed_alert_channels c on c.sales_rep = m.sales_rep
where m.sales_rep is not null and m.sales_rep <> ''
  and c.sales_rep is null
  and coalesce(m.entity,'') <> 'FAW'
  and coalesce(m.is_excluded,false) = false
order by 1;
この3つだけで十分です 毎週すべてを細かく点検する必要はありません。取込ログで件数を見て、重複ゼロを確認し、担当の取りこぼしがなければ正常です。
▲ 目次へ戻る

6【四半期ごと】アカウントマスタの更新

担当営業の割り当てはアカウントマネジメントシートを正としています。四半期ごとの担当変更に合わせて更新してください。

  1. アカウントマネジメントシートを開き、「アカウントALL(営業紐付)」 のシートをCSV形式でダウンロードします。
  2. indeed_import の 👥 アカウントマスタ取込 タブを開きます。
  3. CSVをドロップして取り込みます。
  4. 取込後、第5章の「通知先が決まっていない担当」SQLを実行し、新任の営業がいないか確認します。
  5. 新任がいれば、第8章の手順で通知先を登録します。
過去分をまとめて取り込む場合は順番に注意 複数四半期のシートを取り込むときは、必ず古いQ → 新しいQ の順で実行してください。逆順にすると、古い担当者の情報で上書きされてしまいます。
更新の目安 顧客担当変更が完了する1月・4月・7月・10月の第2週に実施します(KIZUNA本体のマスタ更新と同じタイミング)。
▲ 目次へ戻る

7Slackアラートの運用・点検

掲載終了アラートは自動で動くため、通常は何もする必要がありません。ここでは仕組みと、異常時の点検方法を記載します。

動作の概要

項目設定
実行タイミング平日 朝9時(日本時間)。土日は動きません
通知の対象終了5日以内かつ未通知のキャンペーン
対象外終了日が空欄(日額・月額)/費消率100%以上/終了済み/FAW/自社広告
再通知終了日が延長された場合のみもう一度通知
1通あたり終了日の早い順に20件まで表示。超過分は「ほか○件」
プログラムの場所Supabase → Edge Functions → indeed-alert
自動実行の設定pg_cron のジョブ名 indeed-alert-daily

点検①:自動実行が動いているか

-- status が succeeded なら正常
select jobname, status, start_time, return_message
from cron.job_run_details
where jobname = 'indeed-alert-daily'
order by start_time desc
limit 5;

点検②:スケジュール設定の確認

-- 0 0 * * 1-5 / active=true であればOK(平日9時JST)
select jobname, schedule, active
from cron.job
where jobname = 'indeed-alert-daily';

手動で今すぐ送りたいとき

Supabase → Edge Functions → indeed-alert → Test から実行できます。

本番送信は取り消せません 必ず先に dry で件数を確認してから送信してください。送信した分は「通知済み」として記録され、同じ内容は再送されなくなります。

もう一度テストしたいとき

Slackの投稿を手動で削除し(メッセージ右上の ︙ → 削除)、通知済みの記録をリセットしてから再実行します。

-- 通知済みの記録をリセット(やり直したいときだけ)
update indeed_campaigns
set alert_sent_at = null, alerted_end_date = null
where alert_sent_at is not null;
リセットしたら当日中に送信まで完了させてください リセットしたまま放置すると、翌朝の自動実行で大量に再送されます。
▲ 目次へ戻る

8担当者の異動・入退社があったとき

通知の宛先は indeed_alert_channels テーブルで管理しています。この表を書き換えるだけで宛先が変わり、プログラムの修正は不要です。

現在の対応表

チャンネル対象
#alert_solution奈良・吉川・寒川・堀江・下川
#alert_cs前田・中野・呉・畠山・吉岡
#alert_area山田・河野・中山・末永・長谷川・鈴木・中村・岡野
#alert_other橋田/担当未設定のもの

① まず、実データでの表記を確認する

ここが最重要です 登録する名前は、データ上の表記と一字一句同じでなければ通知が届きません。過去に「中村きらら」と登録して届かなかった事例があります(正しくは「中村きらり」)。必ず下のSQLで実際の表記を確認してから登録してください。
-- 通知先が未登録の担当を表示(ここに出た表記をそのままコピーする)
select distinct m.sales_rep
from indeed_account_master m
left join indeed_alert_channels c on c.sales_rep = m.sales_rep
where m.sales_rep is not null and m.sales_rep <> ''
  and c.sales_rep is null
  and coalesce(m.entity,'') <> 'FAW'
  and coalesce(m.is_excluded,false) = false
order by 1;

② 追加・変更する

-- 追加(すでにあれば宛先を更新)
insert into indeed_alert_channels (sales_rep, channel, note)
values ('山田太郎', '#alert_area', 'エリア')
on conflict (sales_rep) do update
  set channel = excluded.channel,
      note    = excluded.note,
      updated_at = now();

③ 退職・対象外にする

-- 通知を止める(行は残す場合)
update indeed_alert_channels
set is_active = false, updated_at = now()
where sales_rep = '山田太郎';

-- 完全に削除する場合
delete from indeed_alert_channels where sales_rep = '山田太郎';

④ 確認

select sales_rep, channel, note, is_active
from indeed_alert_channels
order by note, sales_rep;

新しいチャンネルを作った場合

CRM-Bot の招待を忘れないでください 新しいSlackチャンネルを通知先にする場合、そのチャンネルにCRM-Botを招待しないと投稿できずエラーになります。
チャンネル名をクリック → インテグレーションタブ → アプリを追加する → CRM-Bot を選択。
▲ 目次へ戻る

9困ったとき(トラブル対応)

取込でエラーが出る/件数が0になる

取込ボタンが押せないまま戻らない

既知の不具合です。Ctrl+Shift+R で再読み込みしてやり直してください。

Slack通知が届かない

  1. 第7章の点検①で status を確認(failed なら return_message を確認)
  2. 点検②で active = true かつ 0 0 * * 1-5 になっているか確認
  3. 対象が0件なだけの可能性もあります。dry=1 で手動実行し件数を確認
  4. 特定の人だけ届かない場合は第8章の表記ゆれを確認

特定の担当だけ #alert_other に流れている

その担当が indeed_alert_channels に登録されていないか、名前の表記が違っています。第8章の手順で確認・修正してください。

Slackの投稿を消したい

メッセージにマウスを乗せ、右上の ︙ → メッセージを削除する。管理者権限があればBotの投稿も削除できます。

自動実行を一時的に止めたい

-- 停止
select cron.unschedule(jobid) from cron.job where jobname = 'indeed-alert-daily';
再開のしかた 停止すると設定そのものが消えるため、再開には登録し直しが必要です。登録用のSQLは引き継ぎメモ(引き継ぎメモ_Indeedキャンペーン管理_v2.md)に記載しています。
なお cron.unschedule('ジョブ名') は存在しないジョブを指定するとエラーになり、同じ画面の他のSQLも実行されなくなります。上記の書き方なら安全です。
▲ 目次へ戻る

10なぜこうなっているか(数値ルールの根拠)

引き継いだ人が「なぜこの手順なのか」を理解できるよう、設計の理由を残します。

毎回まるごと入れ直しても二重にならない理由

キャンペーンは campaign_id、月次明細は campaign_id × 対象年月 をキーに管理しています。同じキーのデータが来たときは行を増やさず既存の行を更新する仕組み(UPSERT)です。

上書きは「新しいから」ではなく「大きいほう」

比較結果
合計費用が高いほう更新する
同額なら表示回数が高いほう更新する
両方同じ据え置き(変更しない)

費用は時間とともに増えるため、大きいほうを残せば結果的に最新が残ります。加えて、取込期間から外れた古い月の値を、小さい値で上書きして壊すのを防ぐ役割があります。

ファイル内での集計ルール

率の定義

企業名が自社名義になっている件

元データの「企業名」列が「株式会社リクルーティングサービス」になっているケースが多数あります。実際のクライアント名は「アカウント名」の "for ○○" の部分です。画面ではこの部分を自動抽出して表示しています。

Indeedの「キャンペーン進行ステータス」を使わない理由

元データのステータスはダウンロード時点の状態が入っており、対象年月時点の状態ではありません。そのため保存せず、終了日から自前で計算しています。

アラートが5日で、画面が10日の理由

土日を挟むと5日では実働3日しかありません。そのため画面は10日前からオレンジで予告し、Slack通知は5日前に本番という二段構えにしています。10日通知にすると月末の集中(7月末は216件)を丸ごと抱え込み、読まれなくなるためです。

▲ 目次へ戻る

11引き継ぎ時に渡すもの一覧

担当を交代する際、以下を引き継ぎ先に渡してください。

アカウント・権限

対象必要な権限確認・付与の方法
KIZUNA CRM管理者ロールusers テーブルの role を確認
Indeed Tableauレポート閲覧・DL共用アカウント rshd_001.ag0007000.tableau@4191.co.jp
パスワードは野沢/大場が保有。再発行はIndeed渉外へ
Supabaseプロジェクトへの参加Supabase管理画面からメンバー招待
Slack4つのalertチャンネルに参加各チャンネルに招待
GitHubリポジトリ閲覧(コード修正時のみ)HISAYOOBA/kizuna-crm(プライベート)

ドキュメント

取り扱い注意 SupabaseのAPIキー、SlackのBot Token、Webhook URLはパスワードと同等です。メール本文や共有ドキュメントに貼らず、必要な場合は直接口頭または安全な手段で伝えてください。GitHubリポジトリは必ずプライベートのままにしてください(キーがコード内に直書きされています)。
▲ 目次へ戻る

12週次チェックリスト(印刷用)

毎週月曜、この順に進めれば完了です。印刷して手元に置いても使えます。

毎週月曜

四半期ごと(1月・4月・7月・10月の第2週)

異動・入退社があったとき

▲ 目次へ戻る