app端-留存分析-周留存率报表开发

用户表
user_id  user_big_type user_mid_type fst_login_date
100001    上海市          徐汇区       2016-01-02


用户登录表
user_id    login_date
100001       2016-03-03


时间维度表
date_id       date_name  date_year
1        1900-01-01    1900
....
40000     2016-01-01    2016


求上海市用户的留存率(用sql语句写以下的逻辑)
维度 第一周的留存率    第二周的留存率    第三周的留存率    第四周的留存率
上海市       50%             30%             20%             15%

注:第几周为第一次登录开始每7天为一周,如用户2016-03-01为首次登录,那么 第一周从2016-03-02至2016-03-08,一天内有多次登录只算一次


/*
--计算日期 2022-03-29                          2-8       9-15   16-22  23-29
user_id    | user_big_type    | fst_login_date | login_date  | w1   | w2   |  w3  |  w4 |fm1| fm2 | fm3 | fm4
100001 |  上海市       |  2022-01-01   | 2022-01-02 | 1      |    0  |  0  |  0   |    1 |  1 |   1  |  1
100001 |  上海市       |  2022-01-01   | 2022-01-08 | 1      |    0  |  0  |  0   |    1 |  1 |   1  |  1
100001 |  上海市       |  2022-01-01   | 2022-01-13 | 0      |    1  |  0  |  0   |    1 |  1 |   1  |  1
100001 |  上海市       |  2022-01-01   | 2022-01-19  | 0      |    0  |  1  |  0  |    1 |  1 |   1  |  1
100001 |  上海市       |  2022-01-01   | 2022-01-30  | 0      |    0  |  0  |  0  |    1 |  1 |   1  |  1
100001 |  上海市       |  2022-01-01   | 2022-01-31  | 0      |    0  |  0  |  0  |    1 |  1 |   1  |  1


100002 |  上海市       |  2022-03-27   | 2022-03-28 | 1      |    0  |  0  |  0  |   1  |  0 |  0   |  0

*/

with tmp as (
--为用户每周是否留存打上标记,如果来了,为1,如果没来为0
--计算周活跃度的分母,计算日期如果离首次登陆日期太近的话,有些数据根本就没有第二周,第三周的数据,会导致分母变大(严格来说应该剔除这些数据)
SELECT
	t1.user_id,
	t1.user_big_type,
	max(if(datediff(t2.login_date,t1.fst_login_date) BETWEEN  1 AND 7  ,1,0)) as w1, --第一周是否活跃的标记,活跃为1,不活跃为0
	max(if(datediff(t2.login_date,t1.fst_login_date) BETWEEN  8 AND 14 ,1,0)) as w2, --第二周是否活跃的标记,活跃为1,不活跃为0
	max(if(datediff(t2.login_date,t1.fst_login_date) BETWEEN 15 AND 21 ,1,0)) as w3, --第三周是否活跃的标记,活跃为1,不活跃为0
	max(if(datediff(t2.login_date,t1.fst_login_date) BETWEEN 22 AND 28 ,1,0)) as w4	--第四周是否活跃的标记,活跃为1,不活跃为0
	max(if(datediff('2022-03-29',t1.fst_login_date)>0,1,0)) as fm1,		--判断用户的第一次登陆时间与当前时间的差值,判断其是否可以参与第一周活跃总人数的计算
	max(if(datediff('2022-03-29',t1.fst_login_date)>7,1,0)) as fm2,		--判断用户的第一次登陆时间与当前时间的差值,判断其是否可以参与第二周活跃总人数的计算
	max(if(datediff('2022-03-29',t1.fst_login_date)>14,1,0)) as fm3,    --判断用户的第一次登陆时间与当前时间的差值,判断其是否可以参与第三周活跃总人数的计算
	max(if(datediff('2022-03-29',t1.fst_login_date)>21,1,0)) as fm4     --判断用户的第一次登陆时间与当前时间的差值,判断其是否可以参与第四周活跃总人数的计算
FROM
	(
	--从用户表中获取上海市的数据
	SELECT
		user_id,
		user_big_type,
		fst_login_date
	FROM tb_user
	WHERE user_big_type='上海市'
	) t1
JOIN
	(
	--一个用户一天可能会登录多次,一天只需要留一天登录数据,jion时可以减少数据量
	SELECT
		user_id,
		login_date
	FROM tb_login
	GROUP BY user_id,login_date
	) t2
ON t1.user_id=t2.user_id
GROUP BY t1.user_id,t1.user_big_type
)

SELECT
	user_big_type as '维度',
	sum(w1)/sum(fm1) as '第一周的留存率',
	sum(w2)/sum(fm2) as '第二周的留存率',
	sum(w3)/sum(fm3) as '第三周的留存率',
	sum(w4)/sum(fm4) as '第四周的留存率',
FROM tmp

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在uni-app开发app时,可能会遇到以下一些安全性问题: 1. 客户漏洞:在app开发中,客户可能存在漏洞,例如不安全的代码编写、未经验证的输入等。攻击者可以利用这些漏洞进行代码注入、跨站脚本攻击(XSS)等。 2. 数据传输安全:在app与服务器之间的数据传输过程中,如果没有适当的加密机制,攻击者可能会截获敏感数据。因此,使用HTTPS协议进行数据传输是一个重要的安全措施。 3. 身份验证与授权:在app中,用户的身份验证和授权是非常重要的。如果身份验证机制存在漏洞,攻击者可以冒充合法用户的身份进行恶意操作。因此,需要使用安全的身份验证和授权机制,例如使用令牌(Token)进行用户身份验证。 4. 代码混淆与反编译:由于uni-app开发app是基于前技术实现的,攻击者可以通过反编译app获取源代码,并进行逆向工程分析。为了增加代码的安全性,可以采用代码混淆技术来对代码进行保护。 5. 动态加载与远程代码执行:uni-app支持动态加载远程代码的功能,这也增加了一定的安全风险。如果不对加载的代码进行有效的验证和过滤,攻击者可以通过远程代码执行漏洞进行攻击。 为了提高app的安全性,开发者可以采取以下措施: - 定期更新与升级:及时更新uni-app框架和相关插件,以修复已知的安全漏洞。 - 代码审计与测试:进行代码审计,发现潜在的安全问题,并进行相关测试以确保代码的安全性。 - 安全编码实践:采用安全编码实践,例如避免使用不安全的函数、过滤用户输入等。 - 强化身份验证与授权:使用安全的身份验证和授权机制,例如使用双因素身份验证、限制权限等。 - 加密与传输安全:使用合适的加密算法和协议保护数据传输的安全性。 以上是一些常见的uni-app开发app时可能遇到的安全性问题和相应的解决方案。开发者在开发过程中应该注重安全性并采取相应的措施来保护用户数据和应用程序的安全。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值