我们正在记录用户在桌面上的iPad应用程序上执行的主要操作流程.每个流都有一个开始(标记为已启动)和一个标记为已取消或已完成的结束,并且不应存在任何重叠事件.
为用户启动,取消或完成的一组流程如下所示:
user_id timestamp event_text event_num
info@cafe-test.de 2016-10-30 00:08:00.966+00 Flow Started 0
info@cafe-test.de 2016-10-30 00:08:15.58+00 Flow Cancelled 2
info@cafe-test.de 2016-10-30 00:08:15.581+00 Flow Started 0
info@cafe-test.de 2016-10-30 00:34:44.134+00 Flow Finished 1
info@cafe-test.de 2016-10-30 00:42:26.102+00 Flow Started 0
info@cafe-test.de 2016-10-30 00:42:49.276+00 Flow Cancelled 2
info@cafe-test.de 2016-10-30 00:42:49.277+00 Flow Started 0
info@cafe-test.de 2016-10-30 00:59:47.337+00 Flow Cancelled 2
info@cafe-test.de 2016-10-30 00:59:47.337+00 Flow Started 0
info@cafe-test.de 2016-10-30 00:59:47.928+00 Flow Cancelled 2
我们想要计算取消流量和完成流量的平均持续时间.为此,我们需要将事件Started与Cancelled或Finished配对.以下代码执行此操作,但无法解决我们遇到的以下数据质量问题:
当客户想要在结束正在进行的流程(Flow1)之前启动新流程(让我们称之为Flow2)时,我们会在拍摄新流程的已启动事件时拍摄已取消的事件.所以Flow1 Cancelled=Flow2 Started.但是,当我们使用窗口函数进行排序时,实际属于不同流的有序事件之间的超前/滞后得到匹配.通过使用此代码:
WITH track_scf AS (SELECT user_id, timestamp, event_text, CASE …