TF
T-Fluencers Docs
Quay lại Wiki

Cập nhật thông số content thủ công#

Mục tiêu: DevOps/Ops update thông số content bypass crawler — dùng cho recovery khi crawler fail hoặc dispute Influencer.

Mục tiêu#

  • Override view/like/comment/share cho 1 content.
  • Backfill missing data khi cron daily miss.
  • Trigger recompute downstream (đối soát, KPI).

Điều kiện tiên quyết#

  • Quyền Admin/Performance edit hoặc DB access.
  • Biết contentId cần update.
  • Có data mới chính xác (từ screenshot, partner report).

Scenarios khi cần update manual#

Scenario 1: Crawler fail vĩnh viễn#

  • MXH đổi API → không crawl được.
  • Content bị MXH unlisted → API trả 0 views.
  • Influencer đã delete bài nhưng nhiệt tình muốn bài được tính.

Scenario 2: Dispute Influencer#

  • Influencer screenshot 100k views, hệ thống ghi 50k.
  • Verify screenshot có khớp thực tế không.
  • Nếu đúng → update manual.

Scenario 3: Backfill legacy data#

  • Migration từ hệ thống cũ.
  • Daily snapshot miss 1–2 ngày.

Các bước thực hiện#

Option A: Qua Admin UI#

Nếu hệ thống có feature Edit statistic trong Admin Portal (xem Duyệt nội dung):

  1. Mở chi tiết content.
  2. Action Edit statistic.
  3. Nhập số mới.
  4. Save → audit log ghi.

Option B: Qua Import Performance#

Xem Import performance (Admin):

  1. Prepare CSV với columns contentId,view,like,comment,share.
  2. Import qua UI.

Option C: Qua DB trực tiếp (DANGEROUS)#

Chỉ khi UI không hoạt động. Cần approval từ Tech Lead.

// MongoDB
db.contents.updateOne(
  {_id: ObjectId("507f1f77bcf86cd799439011")},
  {
    $set: {
      "statistic.view.total": 15000,
      "statistic.like.total": 500,
      "statistic.comment.total": 80,
      "statistic.share.total": 120,
      "manualOverride": true,
      "manualOverrideBy": "<staff_id>",
      "manualOverrideAt": new Date()
    }
  }
)

⚠️ Trực tiếp DB không tạo audit log app-level. Phải manual log action ở nơi khác (Slack, Jira ticket).

Option D: Qua API#

curl -X POST https://api.internal/contents/<id>/statistic \
  -H "Authorization: Bearer <admin_token>" \
  -d '{
    "view": 15000,
    "like": 500,
    "comment": 80,
    "share": 120,
    "reason": "Dispute from creator, verified screenshot"
  }'

Sau khi update#

  1. Verify: mở chi tiết content, check số đã đúng.
  2. Recompute downstream (nếu content thuộc đợt đối soát đang chạy):
    • Trigger recompute reward.
    • Update KPI Dashboard Brand (cache invalidation).

Chi tiết từng bước#

Recompute downstream#

Các entity downstream phụ thuộc content stats:

  1. Reconciliation-item: tiền tính từ views × rate. Update → recompute.
  2. Daily/Post-expiry snapshot: nếu update sau snapshot, snapshot vẫn giữ số cũ. Cần tạo makeup snapshot.
  3. KPI Dashboard Brand: cache hourly. Invalidate bằng: 
    redis-cli DEL "dashboard:kpi:campaign:<id>"
  4. Creator Score: tính lại ở cron daily kế tiếp.

Manual override protection#

Flag manualOverride=true cho content → next cron crawl không overwrite manual value (nếu backend support flag này).

Nếu backend không có flag, phải tạm disable crawler cho content đó (blacklist crawler logic).

Audit checklist#

Sau mỗi manual override:

  • Slack post in #tcb-ops với contentId + before/after.
  • Jira ticket (nếu incident).
  • Email Influencer (nếu do dispute) confirm số đã update.

Lỗi thường gặp#

1. Update xong cron crawl overwrite ngay#

  • Thiếu flag manualOverride. Thêm flag hoặc pause crawler cho contentId.

2. Reward không recompute#

  • Đợt đối soát đã Completed — không đụng được nữa.
  • Nếu đang Running, stop đợt, update, restart.

3. Dashboard Brand vẫn số cũ#

  • Cache. Invalidate Redis key.
  • Wait hourly re-aggregation.

4. Influencer vẫn khiếu nại sau update#

  • Check số đã đúng với screenshot họ gửi.
  • Verify MXH hiện tại (nếu MXH giảm → giải thích decay).

5. Manual override làm tiền chạy sai#

  • Audit action history của content.
  • Rollback: update lại với số trước đó.
  • Compensate: trừ/cộng bù vào ví user nếu cần.

Câu hỏi thường gặp (FAQ)#

Update thủ công có ảnh hưởng Score không?

Có. Next cron creator_score_daily sẽ recompute dùng số mới.

User có thấy số đã update không?

Creator Portal hiển thị số từ contents.statistic → thấy ngay.

Bao nhiêu lần update/content là quá nhiều?

Không có limit cứng. Nhưng > 5 lần/content → flag suspicious (có thể fraud).

Có cron tự động recover crawler fail không?

Có retry trong Asynq, nhưng sau N lần fail vĩnh viễn → dead letter queue. DevOps phải intervene.

Nếu data partner gửi lệch với MXH hiện tại, lấy cái nào?

Tuỳ trust level. Thường:

  • Trust MXH (API canonical).
  • Partner report: chỉ dùng khi API fail.

Liên kết liên quan#

Tham khảo SRS: admin-portal/13-performance