tencent-baidu-tracking

OPPO 渠道接入说明

jlt68 荣耀激活 OAID 日导出

scripts/export_honor_jlt68_oaids.py 会从 tencent_baidu_conversions 导出上海时区前一日的 tag_id=jlt68、media=honor、act=1 数据。输出是 UTF-8、无表头的 CSV，每行一个去重后的 device_id（OAID 原值或 MD5 值），可以直接上传。脚本不会改变 OAID 的大小写；若原始数据中存在 大小写不同但数据库排序规则视为相同的值，数据库会将其去重。

脚本允许导出任意非负数量的 OAID（包括空文件），但会拒绝发布多于 5,000 万条的文件，也会在失败时删除临时文件；成功时通过原子替换 生成文件，避免上传到半写入的 CSV。默认输出目录为 /data/webapp/tencent-baidu-tracking/oaid-export，可通过 OAID_EXPORT_DIR 修改。数据库连接只从以下 环境变量读取，避免密码出现在 crontab 或 Shell 历史中：

OAID_EXPORT_MYSQL_HOST
OAID_EXPORT_MYSQL_PORT       # 可选，默认 3390
OAID_EXPORT_MYSQL_USER
OAID_EXPORT_MYSQL_PASSWORD
OAID_EXPORT_MYSQL_DB         # 可选，默认 adx_tencent
OAID_EXPORT_DIR              # 可选

安装依赖后可先补跑指定日期验证：

python3 -m pip install PyMySQL
export OAID_EXPORT_MYSQL_HOST='your-tidb-host'
export OAID_EXPORT_MYSQL_USER='readonly-user'
export OAID_EXPORT_MYSQL_PASSWORD='***'
python3 scripts/export_honor_jlt68_oaids.py --date 20261101

生产环境建议为运行服务的账号创建一个仅有 SELECT 权限的数据库账号，并将上述变量放入权限为 600 的环境文件（例如 /etc/tencent-baidu-tracking/oaid-export.env）。每天 08:10（上海时区）执行的 crontab 示例：

CRON_TZ=Asia/Shanghai
10 8 * * * set -a; . /etc/tencent-baidu-tracking/oaid-export.env; set +a; /usr/bin/python3 /data/webapp/tencent-baidu-tracking/scripts/export_honor_jlt68_oaids.py >> /data/webapp/tencent-baidu-tracking/log/oaid-export.log 2>&1

首次上线前，在变更窗口执行 reports/add-honor-jlt68-oaid-export-index.sql。该复合索引避免每日全表扫描；若表很大，应由 DBA 使用在线 DDL 流程创建。

业务人员可通过浏览器实时下载，不需要服务器目录或数据库账号：

GET /admin/exports/honor/jlt68/oaids?date=20261101

date 可省略，省略时按上海时区取前一日。接口固定导出 jlt68、honor、act=1，不接受广告位、媒体或 SQL 条件；响应以附件形式下载 CSV，并通过 X-OAID-Count 返回导出前计算的去重 ID 数。因设备标识属于敏感数据，必须仅在已有后台 SSO、内网 VPN 或网关鉴权之后向业务开放 /admin/exports/honor/jlt68/oaids；当前应用本身未提供管理员登录功能。

OPPO APP 数据回传协议使用 POST https://api.ads.heytapmobi.com/api/uploadActiveData。 配置 adx.oppo-conversion-salt、adx.oppo-aes-base64-key 和可选的 adx.oppo-owner-token 后，通过 OppoClient 发送回传：imei、mac、ouId 和 androidId 会按 OPPO v3.23 的 AES/ECB/PKCS5Padding + Base64 规则加密， 签名严格使用发送的原始 JSON：md5(postData + timestamp + salt)。

监测链接必须由 HTTPS 正式域名提供，使用 OPPO 新版宏格式 __REQ__、 __OAID__、__TS__、__OWNERID__。扣量比例通过 deduction_rate 配置项 传入，取值范围为 0-100；实际扣量判定沿用现有渠道的 Redis 原子计数语义。

OPPO Redis 缓存与其他渠道采用相同生命周期：曝光写入的 qk、mediaTrace 两份缓存 TTL 为 3 小时，内容仅保留点击及转化回传需要的字段。点击处理后， 两份缓存一起移除点击 URL 和跳转链接，并按 adx.bid-ttl 重新计时 （默认及当前 prod 配置为 36 小时）。瘦身不会修改当前请求用于跳转的对象。 Stream 仍保存完整事件供后台异步落库，成功后 ACK 并删除消息。 点击按 mediaTrace 查缓存未命中时重新请求广告；转化按 qk 查找仍支持 DB 回查。 已有 Redis key 不会因部署自动缩短 TTL，会在后续写入、点击或自然过期时更新。

jlt130 / jlt11 设备级上报限制

腾讯、vivo、快手、荣耀、OPPO 监测入口的 jlt130、jlt11 按“媒体 + 广告位 + 设备标识 + 事件类型”分别执行滚动 24 小时去重，覆盖正常曝光、点击及点击补曝光路径（腾讯覆盖 v1–v6）。不同媒体、两个广告位独立计数；曝光、点击独立计时，重复请求不刷新去重 TTL。依赖共享 Redis 的原子 SET NX，不依赖 click_id、traceId 或进程内锁。

设备标识按 OAID、IMEI/did、IDFA 顺序选择，支持对应 MD5 字段别名；明文按去除首尾空格后的原始大小写计算 MD5，与同样规则生成的 MD5 入参共用标识。不同类型的设备标识不自动关联。当前入参没有有效设备标识时尝试读取原竞价记录中的设备标识；仍缺失或 Redis 去重操作异常时，只跳过百度监测上报，继续原处理流程。

新增 Redis 数据仅为曝光和点击的 24 小时标识，值为 1。不新增设备级竞价缓存或竞价初始化占位，不修改竞价、按 traceId 查记录、转化关联、缓存 TTL、点击后瘦身和跳转逻辑。重复请求仍可能按原流程竞价，但不会重复发送已占位的百度曝光／点击监测请求。

ClickUrls 仅调用第一个有效 HTTP(S) 链接，空列表不消耗点击资格；曝光仍执行一轮 ShowUrls 列表。两类上报均关闭 HTTP 500 重试，超时或失败不释放已取得的上报资格，避免百度已收到请求但本地未收到响应时重复发送。正常 302 跟随仍保留。其他广告位沿用原逻辑。

历史公共表定时清理

独立后台任务仅删除 adx_proxy.ad_bid_events、adx_proxy.tracking_reports 中 created_at < DATE_SUB(CURRENT_TIMESTAMP(3), INTERVAL 30 DAY) 的记录。按数据库当前时间往前固定 30 天计算，保留最近 30 天的数据；恰好位于边界的记录保留。不会修改现有媒体表及报表归档规则。

两表轮流处理，每批通过一条 DELETE ... WHERE created_at < DATE_SUB(CURRENT_TIMESTAMP(3), INTERVAL 30 DAY) ORDER BY created_at LIMIT 50000 直接删除，每批独立提交，完成后等待 10 秒再处理另一张表。已撤回查 ID 后分 10 次删除的方案：本地及线上实测显示它增加了整轮耗时。等待期间不占用数据库连接；执行前检查停止／锁丢失信号。使用独立 Redis Leader 锁及续约机制，多实例正常运行时只有一个清理线程，不受 skip-leader-election 开关影响。

搜索 [LegacyRetention] mode=direct 或 totalMs= 查看新版日志。记录 deleted、validationMs、deleteMs、totalMs、complete、reason、phase、sqlState、errorCode、error；失败时同一行就能看到出错阶段和原因，不必只凭 complete=false 推测。新版不再查询候选 ID，因此不再输出 selectMs 和 chunks。总耗时不包含批次之间的 10 秒等待。

生产配置默认开启，可通过 ADX_LEGACY_RETENTION_ENABLED=false 关闭；开发、测试配置默认关闭。使用现有 TiDB/MySQL 数据源连接，但 SQL 固定限定上述库名和表名。每张表首次清理前检查 created_at 是日期时间字段且存在以它开头的索引；不满足则跳过该表并记录错误，下次轮到时重查。任务不会自动对大表建索引。上线前可用 SHOW INDEX FROM adx_proxy.ad_bid_events 和 SHOW INDEX FROM adx_proxy.tracking_reports 检查；没有合适索引时，应由数据库维护流程添加 created_at 索引。