4

我写了一段 SQL,却查出来两个投放相关问题

 2 years ago
source link: http://www.wodepm.com/?p=767
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

我写了一段 SQL,却查出来两个投放相关问题

127-840x473.jpg

这是个很有趣的故事,就发生在昨天。
但也是个令人哭笑不得的事情,就发生在这一周。
发生在昨天,是因为的确是昨天我写了 SQL,然后和开发查我写的 SQL,才发现了问题。
说发生在这一周,因为和本周另外一件事情相连,我还特意电话同事,道歉解释了原委。

查投放 click_id SQL:
SELECT *  FROM `lx_toufang_order_click` oc
inner join `lx_toufang_advert_user` AS  au
on oc.`order_no` = au.`order_no`
WHERE au.`deal_time`!=”
主要的目的是查出来已成交用户在投放时的点击事件。

通过这个,和开发一起发现了两个问题:
1.当前前端上报和后端记录的渠道不一致。排查前端代码,确认上报的是 gdt(广点通),但后端记录的是 tt(头条)。
2.排查后端库表,以及后台记录值,确定了当前只记录和保存了 tt(头条)投放的 click_id。

这对业务有啥影响呢?

1.和本周内我同步给投放团队的信息不一致。告诉他们只回收、记录的是 gdt,但后台、数据库表、日志只记录了 tt。
2.tt 可以进一步提供数据,去优化投放,而 gdt 不能。周五还跟投放和 gdt 媒体一起沟通了,通过提供 click_id 排查投放下降的原因,以期使投放数据有所回升。尼玛,打脸了。

后续做啥呢?

首先,是道歉啊。因为产品和开发问题,导致信息沟通不一致,更严重的是影响了业务进展。
其次,整理了后续一些 todolist:
1.把 tt 的数据导出来了,给了投放小伙伴进一步分析和整理,并推动和媒体继续对接。
2.和 gdt 投放小伙伴沟通了几个事:没有 click_id 情况下有没有其他方式可以继续排查的思考;和媒体继续沟通,寻找更加有效的方式提升投放质量;我们自己思考其他的投放优化思路。
3.出了需求,修正现有的不一致,并新增 gdt 和 baidu 的 click_id 补齐。

哎……
历史数据啊​,
找不回来,找不回来。
都是钱啊,都是钱啊。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK