惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

The Cloudflare Blog
U
Unit 42
F
Fortinet All Blogs
雷峰网
雷峰网
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
月光博客
月光博客
Y
Y Combinator Blog
罗磊的独立博客
V
Visual Studio Blog
大猫的无限游戏
大猫的无限游戏
J
Java Code Geeks
量子位
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
爱范儿
爱范儿
B
Blog RSS Feed
aimingoo的专栏
aimingoo的专栏
有赞技术团队
有赞技术团队
T
Tailwind CSS Blog
Microsoft Security Blog
Microsoft Security Blog
L
LangChain Blog
I
InfoQ
博客园 - 叶小钗
博客园 - 聂微东
Last Week in AI
Last Week in AI

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
实现微信UnionID与多个系统UserID关联方法
Kuang扶正义的匡 · 2023-09-28 · via 人人都是产品经理

下边这篇文章笔者将介绍在用户系统账号与微信账号一对多的情况下,如何设计来实现数据的互通的相关信息。有需要了解相关信息的同学可以了解了解。

一、背景与目的

如果我们系统的用户账号与微信账号是一对一的关系,那么我们可以轻松地将系统数据与微信生态应用中的数据联通起来。

但是由于业务需求或特殊情况,我们的用户系统账号与微信账号往往无法保持一对一的映射关系,例如允许用户在小程序之间切换账号,或者将多个系统子账号的通知推送到同一个微信公众号中。本文将介绍在用户系统账号与微信账号一对多的情况下,如何设计来实现数据的互通。

二、方案设计

1. 微信用户体系调研

对于同一个用户,在同一个微信开放平台账号下的不同移动应用、网站应用和公众号(包括小程序)中,OpenID不同,但UnionID相同。例如,如果您拥有小程序A、小程序B和一个微信公众号,并将它们绑定到同一个微信开放平台账号下,当微信用户进入小程序A、小程序B或公众号时,他们获得的UnionID是相同的。这意味着可以根据UnionID查询当前微信用户在同一开放平台下的每个小程序或公众号中的数据,从而实现了数据的高效共享。

2. 设计思路

  • 为满足业务需求,应允许一个UnionID绑定多个UserID;
  • 根据微信用户体系调查,应允许一个UnionID对应多个不同应用(在同一开放平台下)的OpenID,并且确保UnionID和各个OpenID之间具有唯一性(即一个UnionID对应不同应用的OpenID不会重复);
  • 为提高产品易用性并降低用户操作成本,UserID、UnionID和OpenID之间的关联操作应灵活,不要求用户按照特定顺序执行。例如,用户可以先关注公众号,然后登录小程序以完成关联,也可以通过登录小程序后再关注公众号来完成关联;
  • 为确保账户信息的安全性和操作准确性,不允许一个UserID绑定多个UnionID。当UserID已经关联了一个UnionID时,应将其更新为当前登录的UnionID和OpenID;
  • 在数据新增和更新时,应同时将UserID和UnionID作为主键,以避免一个UserID对应多个UnionID的数据存在。

3. 设计方案

根据上述解决方案思路,我们为以下4个场景进行了详细设计:登录小程序、通过Web扫码关注公众号、通过微信关注公众号以及取消关注公众号。通过这些设计,我们实现了以下效果:

  • 一个微信账号可以登录多个系统账号,并且多个系统账号的信息可以推送至该微信的公众号中。
  • 用户可以在这4个场景中随意执行,不受顺序限制,而仍然能够确保系统账号与小程序、公众号的准确关联。

登录小程序场景:

Web扫码关注公众号:

微信里关注公众号:

取消关注公众号:

三、最后

本文详细探讨了在用户系统账号与微信账号无法一一对应时,如何设计系统以实现数据的互通。实现过程中,需注意用户操作的灵活性和信息的安全性。用户可以在不同的场景中自由切换,而系统能够确保账号之间的准确关联。同时,通过将UserID和UnionID作为主键,我们避免了一个UserID对应多个UnionID的数据冲突,确保了数据的一致性和准确性。

本文由 @Kuang扶正义的匡 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。