毎週月曜のデータ取込・アラート運用・引き継ぎ手順
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 テーブルで確認・変更します。Indeedが提供するTableau上のレポートから、月間キャンペーンパフォーマンスを過去6か月分ダウンロードします。
| URL | https://prod-apnortheast-a.online.tableau.com/ |
|---|---|
| ユーザー名 | rshd_001.ag0007000.tableau@4191.co.jp |
| パスワード | 野沢または大場に問い合わせ(このマニュアルには記載しません) |
| 表示名 | 侑平野沢 |
| アカウント管理者 | 野沢侑平/大場久代 |
| パスワード再発行 | Indeedの渉外担当に相談 |
ログイン後、探索 → PROD → Campaign Performance Dashboard の順に開きます。
画面上部に 「Partner Campaign Performance Dashboard/パートナーキャンペーンパフォーマンスダッシュボード」 と表示されていれば正しい画面です。
https://kizuna-crm.pages.dev/indeed_import を開き、管理者アカウントでログインします。| 表示される項目 | 意味と見かた |
|---|---|
| 元データの行数 | Excelの行数。6か月分で概ね14,000〜15,000行前後 |
| 重複排除後の件数 | キャンペーン単位にまとめた件数。6か月分で概ね9,000〜10,000件前後 |
| 新規/更新/スキップ | 新しく追加される数、上書きされる数、変更なしの数 |
| 未分類 | 担当営業が特定できなかったもの。第4章で対応 |
取込後、担当営業が特定できなかったキャンペーンが「未分類」として残ることがあります。放置すると、そのキャンペーンのSlack通知が #alert_other に流れ、担当者本人に届きません。
担当営業は次の順で自動判定されます。手動でのひも付けは、これでも決まらなかった分です。
取込が正しく反映されたか、画面とSQLで確認します。慣れれば2〜3分です。
https://kizuna-crm.pages.dev/indeed_campaign を開きます。-- いつ・何件取り込んだかの履歴
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;
担当営業の割り当てはアカウントマネジメントシートを正としています。四半期ごとの担当変更に合わせて更新してください。
indeed_import の 👥 アカウントマスタ取込 タブを開きます。掲載終了アラートは自動で動くため、通常は何もする必要がありません。ここでは仕組みと、異常時の点検方法を記載します。
| 項目 | 設定 |
|---|---|
| 実行タイミング | 平日 朝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 = 1 を追加して実行dry の行を削除して実行dry で件数を確認してから送信してください。送信した分は「通知済み」として記録され、同じ内容は再送されなくなります。Slackの投稿を手動で削除し(メッセージ右上の ︙ → 削除)、通知済みの記録をリセットしてから再実行します。
-- 通知済みの記録をリセット(やり直したいときだけ)
update indeed_campaigns
set alert_sent_at = null, alerted_end_date = null
where alert_sent_at is not null;
通知の宛先は indeed_alert_channels テーブルで管理しています。この表を書き換えるだけで宛先が変わり、プログラムの修正は不要です。
| チャンネル | 対象 |
|---|---|
| #alert_solution | 奈良・吉川・寒川・堀江・下川 |
| #alert_cs | 前田・中野・呉・畠山・吉岡 |
| #alert_area | 山田・河野・中山・末永・長谷川・鈴木・中村・岡野 |
| #alert_other | 橋田/担当未設定のもの |
-- 通知先が未登録の担当を表示(ここに出た表記をそのままコピーする)
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;
既知の不具合です。Ctrl+Shift+R で再読み込みしてやり直してください。
status を確認(failed なら return_message を確認)active = true かつ 0 0 * * 1-5 になっているか確認dry=1 で手動実行し件数を確認その担当が indeed_alert_channels に登録されていないか、名前の表記が違っています。第8章の手順で確認・修正してください。
メッセージにマウスを乗せ、右上の ︙ → メッセージを削除する。管理者権限があればBotの投稿も削除できます。
-- 停止
select cron.unschedule(jobid) from cron.job where jobname = 'indeed-alert-daily';
引き継ぎメモ_Indeedキャンペーン管理_v2.md)に記載しています。cron.unschedule('ジョブ名') は存在しないジョブを指定するとエラーになり、同じ画面の他のSQLも実行されなくなります。上記の書き方なら安全です。引き継いだ人が「なぜこの手順なのか」を理解できるよう、設計の理由を残します。
キャンペーンは campaign_id、月次明細は campaign_id × 対象年月 をキーに管理しています。同じキーのデータが来たときは行を増やさず既存の行を更新する仕組み(UPSERT)です。
| 比較 | 結果 |
|---|---|
| 合計費用が高いほう | 更新する |
| 同額なら表示回数が高いほう | 更新する |
| 両方同じ | 据え置き(変更しない) |
費用は時間とともに増えるため、大きいほうを残せば結果的に最新が残ります。加えて、取込期間から外れた古い月の値を、小さい値で上書きして壊すのを防ぐ役割があります。
元データの「企業名」列が「株式会社リクルーティングサービス」になっているケースが多数あります。実際のクライアント名は「アカウント名」の "for ○○" の部分です。画面ではこの部分を自動抽出して表示しています。
元データのステータスはダウンロード時点の状態が入っており、対象年月時点の状態ではありません。そのため保存せず、終了日から自前で計算しています。
土日を挟むと5日では実働3日しかありません。そのため画面は10日前からオレンジで予告し、Slack通知は5日前に本番という二段構えにしています。10日通知にすると月末の集中(7月末は216件)を丸ごと抱え込み、読まれなくなるためです。
▲ 目次へ戻る担当を交代する際、以下を引き継ぎ先に渡してください。
| 対象 | 必要な権限 | 確認・付与の方法 |
|---|---|---|
| KIZUNA CRM | 管理者ロール | users テーブルの role を確認 |
| Indeed Tableau | レポート閲覧・DL | 共用アカウント rshd_001.ag0007000.tableau@4191.co.jpパスワードは野沢/大場が保有。再発行はIndeed渉外へ |
| Supabase | プロジェクトへの参加 | Supabase管理画面からメンバー招待 |
| Slack | 4つのalertチャンネルに参加 | 各チャンネルに招待 |
| GitHub | リポジトリ閲覧(コード修正時のみ) | HISAYOOBA/kizuna-crm(プライベート) |
indeed_manual.html)… システムの使い方はこちら引き継ぎメモ_Indeedキャンペーン管理_v2.md)… 技術的な設計と経緯毎週月曜、この順に進めれば完了です。印刷して手元に置いても使えます。
indeed_import の「📥 キャンペーン取込」にドロップindeed_campaign を開き、件数と🔴終了5日以内を目視確認indeed_alert_channels に追加・変更・無効化