1. 背景介绍 微信开放平台使用 HTTPS 协议来确保通信的安全性。在开发者调用微信开放平台 API 的过程中，需要在其操作系统或执行环境（如 JRE 等）中部署权威机构的根证书，以验证微信开放平台服务器证书的真实性，进而验证微信服务器及其域名的真实性。 受 Mozilla 信任库的最新根证书信任策略影响（全球所有 CA 的可信根证书需每15年更换一次，超过此时间的可信根将逐渐失去 Mozilla 的信任），DigiCert 将逐步停止使用旧的根证书体系（G1）来颁发 TLS/SSL 证书，转而采用新的根证书体系（G2）。 当前微信开放平台服务器证书的颁发根 CA 是 Digicert Global Root CA (G1)，微信开放平台计划于 2024年10月22日 0:00 开始，逐步启用采用 DigiCert Global Root G2 根 CA 颁发的新服务器证书，开发者应仔细阅读本指引，并完成相关验证和修正，以免影响正常服务。 注意： 1）所有通过 api.weixin.qq.com 调用的 API 都可能受影响，开发者需要在 2024年10月22日 0:00 之前参考指引完成相关验证和修正。 2）大多数操作系统和执行环境都默认内置了 DigiCert Global Root G2 根证书，因此大多数系统无需改动即可兼容新服务器证书。但如果开发者的服务器未内置 G2 根证书，或程序代码指定使用旧的 G1 根证书，则会受到影响，将出现服务中断的问题。我们建议及时移除指定旧根证书代码，采用系统自带的信任库进行验证，同时确保系统内置有 DigiCert Global Root G2 根证书。 3）新的 G2 根体系采用更高安全性的 SHA256 签名算法，且依然兼容当前主流的操作系统和移动设备，主流环境兼容情况如下： [图片] 对应的根证书文件请参考： Baltimore CyberTrust Root：Download PEM、Download DER/CET Digicert Global Root CA：Download PEM、 Download DER/CRT Digicert Global Root G2：Download PEM、 Download DER/CRT 2. 开发须知 开发者需确认与微信开放平台对接的服务器系统可兼容新的服务器证书，并参考“验证指引”章节的方法，在 2024年10月22日 0:00 之前完成验证： • 如果验证结果正常，开发者不需要做其它任何事情 • 如果验证结果异常，开发者需要修改相关的系统实现或配置，且需最晚于 2024年10月22日 0:00 之前前完成修正，否则开发者的业务系统与微信开放平台系统之间将不能正常进行 HTTPS 通讯，将影响业务正常运行。 开发者在验证和修正过程中遇到问题，可在小程序专区发帖咨询，我们会有专人进行解答回复。 3. 验证指引 验证方式：绑定 host，请求已部署新证书的微信开放平台服务器 开发者可通过修改操作系统的 hosts 文件来绑定 IP，例如，可在 hosts 文件中新增一行如下内容，实现将域名"api.weixin.qq.com"绑定到新证书环境： 81.69.216.137 api.weixin.qq.com 在 Linux 系统下，hosts文件的完整路径为"/etc/hosts"，在Windows系统下，hosts 文件的完整路径为"C:\Windows\System32\drivers\etc\hosts"。 注意： 1、host 环境可以访问的接口与正式环境完全一致，且真实生效，被视为生产正式业务。在验证之前，请充分评估对贵司业务系统以及业务的影响 2、验证完成后，请及时恢复服务器上的 host 配置，微信开放平台服务器证书更新完成后，此处使用的 IP 会被关停。 3、需要用和生产环境相同的操作系统、执行环境、开发语言及程序逻辑进行验证。使用 curl 等命令行工具验证成功，并不代表你的系统支持了新的服务器证书。 4、逐一验证所有正在调用的微信开放平台接口，如果均能正常使用，说明系统支持微信开放平台新的服务器证书。反之，则需要根据修正指引排查问题并修正。 4. 修正指引 大部分情况下，验证失败是以下两种情况导致的： 情况一：程序中指定了根证书，但是指定的根证书中仅包含了旧的 G1 根证书。 情况二：服务器上没有部署新的 G2 根证书。 可通过以下两个方案修正: 方案一：删除指定根证书的代码。当程序中不指定根证书时，会使用系统自带的根证书。绝大部分系统中已内置了新的 G2 根证书，所以删除指定根证书的代码，不会影响到你的现有业务。 方案二：更新根证书。往 truststore 或者根证书信任文件中追加新的 G2 根证书（注意：追加新的根证书时，需要保留老的G1根证书）。 推荐使用“方案一”来修正，该方案的兼容性更好。原因是：新的 G2 根证书将于 2029年4月15日不再被 Mozilla 信任，到时候同样要更换新的根证书。使用方案一修复，你的系统中很可能已内置了后续需更换使用的根证书，从而不受影响。如果使用方案二进行修复，在 2029年4月15日仍可能需安装新的根证书。 下面介绍各种开发语言可能碰到的问题及解决方法： JAVA常见错误 javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target 可能原因: 代码中设置了 javax.net.ssl.trustStore 。 可以在代码中搜索关键字“trustStore” 或者 “TrustManager” 来确认 解决方法: 方法一、删除掉指定[代码]javax.net.ssl.trustStore[代码]的代码 方法二、安装新的根证书, 往指定的trustStore 中添加新的根证书。操作命令：keytool -importcert -keystore cacerts -storepass changeit -noprompt -file ./DigiCertGlobalRootG2.crt -alias digicertglobalrootg2 C++常见错误 cURL error 60: SSL certificate: unable to get local issuer certificate. CURLE_SSL_CACERT (60) peer certificate cannot be authenticated with known CA certificates. 可能原因: 代码中设置了[代码]CURLOPT_CAINFO[代码]。 可以在代码中搜索关键字“CURLOPT_CAINFO”来确认 解决方法： 方法一、删除掉[代码]curl_easy_setopt(pCurl,CURLOPT_CAINFO,"./rootca.pem")[代码]相关的代码 方法二、更新rootca.pem。用libcurl官网最新的 https://curl.haxx.se/ca/cacert.pem 替换即可 PHP常见错误 cURL error 60: SSL certificate: unable to get local issuer certificate. CURLE_SSL_CACERT (60) peer certificate cannot be authenticated with known CA certificates. 可能原因: 使用libcurl时设置了[代码]CURLOPT_CAINFO[代码]。可以在代码中搜索关键字“CURLOPT_CAINFO”来确认。 解决方法： 方法一、删除掉类似[代码]curl_setopt(pCurl， CURLOPT_CAINFO， "./rootca.pem");[代码]的代码 方法二、更新rootca.pem。用libcurl官网最新的https://curl.haxx.se/ca/cacert.pem 替换即可 C#常见错误 RemoteCertificateValidationCallback 设置的回调函数返回 false 可能原因: 操作系统中没有新的根CA 解决方法: 安装新的根证书 Python常见错误 SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) 可能原因: 代码中用 verify 指定了根证书文件。 可以在代码中搜索关键字“verify”来确认。类似的代码如: [代码]response = requests.post( "https://api.mch.weixin.qq.com/secapi/pay/refund"， verify="./rootca.pem", …… ); [代码] 解决方法： 方法一、删除verify参数 方法二、更新[代码]rootca.pem[代码]。用libcurl官网最新的https://curl.haxx.se/ca/cacert.pem 替换即可 go常见错误 x509: certificate signed by unknown authority . 可能原因: 发起https时， 用 RootCAs指定了根证书文件。 可以在代码中搜索关键字 “RootCAs” 来确认。类似的代码如: [代码]roots.AppendCertsFromPEM([]byte(rootPEM)) tr := &http.Transport{ TLSClientConfig: &tls.Config{RootCAs: roots}， } client := &http.Client{Transport: tr} [代码] 解决方法： 方法一、删除配置项RootCAs 方法二、更新[代码]rootca.pem[代码]。用libcurl官网最新的https://curl.haxx.se/ca/cacert.pem 替换即可 Ruby常见错误 SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed 可能原因: 发起https时， 用[代码]ssl_ca_file[代码]或者[代码]cert_store[代码]指定了根证书文件。 可以在代码中搜索关键字“ssl_ca_file” 或者 “cert_store” 来确认。类似的代码如: [代码] "https://api.mch.weixin.qq.com/secapi/pay/refund"， :ssl_client_cert => OpenSSL::X509::Certificate.new(File.read("./apiclient_cert.pem "))， :ssl_client_key => OpenSSL::PKey::RSA.new(File.read("./apiclient_key.pem "))， :ssl_ca_file => "./rootca.pem"， :verify_ssl=>OpenSSL::SSL::VERIFY_PEER).post(data); [代码] 或者 [代码]sock.cert_store.add_file('/usr/lib/ssl/certs/weixin/rootca.pem') [代码] 解决方法： 方法一、删除 [代码]ssl_ca_file[代码]及 cert_store 指定的参数 方法二、更新rootca.pem。用libcurl官网最新的https://curl.haxx.se/ca/cacert.pem 替换即可 NodeJs常见错误 Caught exception: Error: CERT_UNTRUSTED 可能原因: 代码中用 ca 指定了根证书文件。 可以在代码中搜索关键字“ca” 或者 “rootca” 来确认。类似的代码如: [代码] hostname: api.mch.weixin.qq.com ', pfx: await readFile('./apiclient_cert.p12'), ca: await readFile('./rootca.pem'), }; const req = https.request(options, (res) => { …… [代码] 解决方法： 方法一、删除ca指定的参数 方法二、更新[代码]rootca.pem[代码]。用libcurl官网最新的https://curl.haxx.se/ca/cacert.pem 替换即可 其它语言请参考对应的TLS/SSL库相关手册。 5. 常见问题 Q1：什么是服务器证书？ A：服务器证书通常又叫“SSL 证书”、“HTTPS 证书”，它由权威 CA 机构颁发，用于对网站进行身份鉴定，并使客户端与网站之间通过 TLS/SSL 协议建立起安全传输通道。微信开放平台的服务器证书是由权威机构 DigiCert 颁发，开发者调用微信开放平台 API 时，能通过该证书来认证微信服务器身份。 Q2：什么是根证书？ A：根证书是权威 CA 机构给自己颁发的证书，是信任链的起始点，是证书颁发机构（CA）与用户建立信任关系的基础。操作系统、浏览器、TLS/SSL 开发库通常随软件发行包预置其信任的权威机构的根证书。 Q3：微信开放平台为什么要更换服务器证书？ A：根证书存在有效期，根证书到期后无法继续被用来校验服务器证书。 因此，微信开放平台向权威机构（CA）申请了新的服务器证书。避免在老的根证书过期后，开发者调用微信开放平台 API 时出现问题。 Q4：微信开放平台更换服务器证书，需要开发者配合做哪些事情？ 一、验证你的系统是否兼容微信开放平台新的服务器证书。 二、若支持的话，不需要做任何操作。若不支持，需要参考修正指引排查原因并修正。 注意： a）开发者按指引进行验证或安装新的根证书, 不会产生任何费用。 b）开发者正在使用的其它 HTTPS 证书不需要更换或者升级。 Q5：开发者如何核实服务器上是否已内置了G2根证书？ A： 以 Linux 系统为例。Linux 系统信任根证书库的保存位置因发行版本不同而有所差异：Debian/Ubuntu：/etc/ssl/certs/ca-certificates.crt CentOS/RHEL/Fedora/TencentOS：/etc/pki/tls/certs/ca-bundle.crt 开发者可以使用以下命令来核实系统是否已内置了G2根证书 [代码]grep "DigiCert Global Root" /etc/pki/tls/certs/ca-bundle.crt # DigiCert Global Root CA # DigiCert Global Root G2 [代码] 备注：示例显示系统已内置了G1和G2根证书 Q6：微信开放平台更换证书前，可以提前安装根 CA 证书吗？ A： 必须提前安装，且建议在 2024年10月22日 0:00 之前提前安装。因为从 2024年10月22日 0:00开始，微信开放平台会在生产环境逐步灰度启用新服务器证书，以校验开发者的系统是否兼容新证书。微信开放平台在更换新证书的过程中，会同时使用新老两个服务器证书，开发者要能正常处理这种情况。因此，开发者的服务器上需要包含新老两个根证书。 Q7：开发者需在什么时候完成验证和修正？不验证会有什么影响？ A： 开发者应在 2024年10月22日 0:00 之前完成验证和修正。如果开发者侧系统的实现方式已能兼容新的服务器证书，那么不会影响业务；如果开发者侧系统的实现方式不能兼容新的服务器证书，那么会导致开发者的系统与微信开放平台的系统不能正常交互，影响业务。 Q8：如果开发者无法按时完成兼容性修正，在微信开放平台灰度新证书时遇到异常应如何处理？ A： 如果开发者的系统经验证是不能兼容新证书的，开发者应在 2024年10月22日 0:00 之前完成修正。如果无法按时完成修正，我们届时可提供仍使用旧证书的临时环境，开发者可通过 host 绑定 IP 的方式使用，以临时规避证书更换产生的影响。请务必在2024年10月22日 0:00 之前完成系统修正，并取消绑定临时环境IP，恢复以正常的方式对接微信开放平台的生产正式环境。 6. 特别提醒 1）为提前发现开发者“是否会受到证书更换的影响？”“有没有升级完根证书？”，微信开放平台将于 2024年10月22日 0:00 开始，把开发者的部分请求转发到部署了新证书的服务器上，并逐步提升灰度比例。当开发者不支持新的服务器证书时，会出现 SSL 相关的错误，通常情况下重试即可恢复。 2）根证书升级仅跟服务器和应用程序相关，与 APPID 没关系。只要在同一台服务器升级完成后，该服务器上使用的所有 APPID 都可以正常使用的。 3）如果你是通过代理服务器向微信开放平台发起请求，那么需要修改代理服务器的配置。 7. 联系我们 如果开发者在验证或者修正问题的过程中遇到困难，可在小程序专区发帖咨询，我们会有专人进行解答回复。 8. 附录 DigiCert 原文公告 ：DigiCert root and intermediate CA certificate updates 2023

重磅打造的小程序学习路径课，从微信小程序到微信云开发体系化的学习，带来更加顺畅的学习体验。

公告更新时间：2021年04月15日考虑到近期开发者对小程序登录、用户信息相关接口调整的相关反馈，为优化开发者调整接口的体验，回收wx.getUserInfo接口可获取用户授权的个人信息能力的截止时间由2021年4月13日调整至2021年4月28日24时。为优化用户的使用体验，平台将进行以下调整： 2021年2月23日起，若小程序已在微信开放平台进行绑定，则通过wx.login接口获取的登录凭证可直接换取unionID2021年4月28日24时后发布的小程序新版本，无法通过wx.getUserInfo与<button open-type="getUserInfo"/>获取用户个人信息（头像、昵称、性别与地区），将直接获取匿名数据（包括userInfo与encryptedData中的用户个人信息），获取加密后的openID与unionID数据的能力不做调整。此前发布的小程序版本不受影响，但如果要进行版本更新则需要进行适配。新增getUserProfile接口（基础库2.10.4版本开始支持），可获取用户头像、昵称、性别及地区信息，开发者每次通过该接口获取用户个人信息均需用户确认。具体接口文档：《getUserProfile接口文档》由于getUserProfile接口从2.10.4版本基础库开始支持（覆盖微信7.0.9以上版本），考虑到开发者在低版本中有获取用户头像昵称的诉求，对于未支持getUserProfile的情况下，开发者可继续使用getUserInfo能力。开发者可参考getUserProfile接口文档中的示例代码进行适配。请使用了wx.getUserInfo接口或<button open-type="getUserInfo"/>的开发者尽快适配。开发者工具1.05.2103022版本开始支持getUserProfile接口调试，开发者可下载该版本进行改造。 小游戏不受本次调整影响。 一、调整背景很多开发者在打开小程序时就通过组件方式唤起getUserInfo弹窗，如果用户点击拒绝，无法使用小程序，这种做法打断了用户正常使用小程序的流程，同时也不利于小程序获取新用户。 二、调整说明通过wx.login接口获取的登录凭证可直接换取unionID 若小程序已在微信开放平台进行绑定，原wx.login接口获取的登录凭证若需换取unionID需满足以下条件： 如果开发者帐号下存在同主体的公众号，并且该用户已经关注了该公众号如果开发者帐号下存在同主体的公众号或移动应用，并且该用户已经授权登录过该公众号或移动应用2月23日后，开发者调用wx.login获取的登录凭证可以直接换取unionID，无需满足以上条件。 回收wx.getUserInfo接口可获取用户个人信息能力 4月28日24时后发布的新版本小程序，开发者调用wx.getUserInfo或<button open-type="getUserInfo"/>将不再弹出弹窗，直接返回匿名的用户个人信息，获取加密后的openID、unionID数据的能力不做调整。 具体变化如下表： [图片] 即wx.getUserInfo接口的返回参数不变，但开发者获取的userInfo为匿名信息。  [图片] 此外，针对scope.userInfo将做如下调整： 若开发者调用wx.authorize接口请求scope.userInfo授权，用户侧不会触发授权弹框，直接返回授权成功若开发者调用wx.getSetting接口请求用户的授权状态，会直接读取到scope.userInfo为true新增getUserProfile接口 若开发者需要获取用户的个人信息（头像、昵称、性别与地区），可以通过wx.getUserProfile接口进行获取，该接口从基础库2.10.4版本开始支持，该接口只返回用户个人信息，不包含用户身份标识符。该接口中desc属性（声明获取用户个人信息后的用途）后续会展示在弹窗中，请开发者谨慎填写。开发者每次通过该接口获取用户个人信息均需用户确认，请开发者妥善保管用户快速填写的头像昵称，避免重复弹窗。 插件用户信息功能页 插件申请获取用户头像昵称与用户身份标识符仍保留功能页的形式，不作调整。用户在用户信息功能页中授权之后，插件就可以直接调用 wx.login 和 wx.getUserInfo 。 三、最佳实践调整后，开发者如需获取用户身份标识符只需要调用wx.login接口即可。 开发者若需要在界面中展示用户的头像昵称信息，可以通过<open-data>组件进行渲染，该组件无需用户确认，可以在界面中直接展示。 在部分场景（如社交类小程序）中，开发者需要在获取用户的头像昵称信息，可调用wx.getUserProfile接口，开发者每次通过该接口均需用户确认，请开发者妥善处理调用接口的时机，避免过度弹出弹窗骚扰用户。 微信团队 2021年4月15日

背景：在接触过上百家头部客户中，诊断和参与了数百次的数据体系搭建工作。几乎80%的App都没有科学的埋点规划，只采集显性数据，而更深层的与事件、参数相关的隐性数据，都没有采集到。埋点规划并不难！但为什么大部分企业都做的不太好？埋点规划需要整合产品、运营、技术和业务等跨部门的需求，运营同学不太懂技术、技术同学不太懂业务、产品同学不太懂埋点，这问题该如何解？在友盟+《战疫求生，开发者的危与机》直播公开课上，友盟+业务专家张跃梳理一套方法论。带你从埋点的坑、结构化的埋点方案、高效的事件管理入手进行结构化埋点。   一、           在埋点前，先带你避开埋点的深坑   第一坑：遗漏，指的是埋点采集不全面，有可能重要的数据并没有采集到，会对数据分析造成比较直接的影响，出现这个问题的原因是前期数据分析需求不清晰。   第二坑：杂乱。指的是数据采集比较零散，可以理解为前期并没有进行事件结构化的设计，通常是想到一个需求，就把这个需求提供给技术进行埋点。这种称之为“扁平化”的埋点方式，例如：某一个位置或者某一个功能的点击行为，就当做一个事件进行采集，看上去采集和查看很容易，但随着时间跟需求的增加，当采集了大量零散的事件之后，需要在统计工具中通过分组分析时，就会比较麻烦。   第三坑：低效。不同于杂乱，杂乱是任何行为数据都会直接当事件去进行采集，没有利用参数去进行结构化的设计。低效指的是在事件设计的时候，会去做结构化处理。但事件设计的参数逻辑会有问题，通常都是以大的页面这种框架的思维去进行设计。   举个例子：部分客户在设计时，会按照页面的思路去进行事件采集，页面上有推荐位，还有很多功能按钮的点击，那么就会把这个页面所有的点击行为都归到一个事件，并且点击具体的按钮和内容都当做参数传回来。但这里埋着两个雷区：1、在分析数据时，例如想了解整个用户浏览内容的情况，或者是想了解某个功能（搜索引擎）整体使用情况，按照如上设计，内容和功能的采集都分布在每一个事件中了，这样后面再归类、分析就非常不方便。2、当产品结构产生变化时，原有事件调整概率会比较大，因为之前都是按页面结构去设计，页面的调整直接影响事件采集。   第四坑：无用。指的是数据虽然采集了，但分析时根本用不上，这个问题主要有2个原因导致，一是前期需求不太清晰，另一个是之前的采集需求都是由不同人提出的，由于中间人员变动，很多采集需求就不清楚了，并且也不敢下掉，因为并不清楚这个事件是否还有人使用。   第五坑：复用。指的是事件重复采集，或者是需求重复，这个同样是与多个人提需求有关，并没有一个人去做整合管理，或者是说，没有一个工具去帮忙我们做管理。   二、如果想要避免这些坑，就需要坚守五个原则： 1、需求清晰。 2、合理设计。 3、实施规范。 4、结果可验 5、规范管理。     三、                    埋点方法论——五步一全（ODEIIC），需要多角色参与统筹决策   第一、需求梳理。在梳理埋点设计的时候，通常会以产品、运营和市场以及KPI三个视角去切入。通常，产品关注的核心业务点会聚焦在内容和功能上，运营和市场关注的业务点在拉新、留存、促活和转化上，KPI视角会聚焦在转化与收入上，但也需要根据客户的实际情况而定。   同时，会把不同视角的业务需求再转化成需要关注的核心数据，如产品运营在内容上所需要关注用户浏览、内容的转发或者是偏好，针对功能使用会关注注册、登录、搜索等这些功能的使用情况。 [图片]   业务需求拆解成核心数据后，针对每一个核心数据进行维度的细分，如内容方面：会按照标题、频道或者是标签，进行拆分分析。那么我们针对功能方面，会按照功能使用情况以及步骤的转化去进行分析。通过要分析的关键点，就可以把细分维度拆出来，最后还会再加上一些通用的维度，例如可以对单个用户或者某一个地区的用户进行深度分析。   以产品视角的需求样例，产品通常情况下会聚焦内容与功能上的使用，但在需求收集时都是分散和抽象的，例如：业务需要分析内容偏好和推荐效果以及内容受欢迎的程度。那在这个环节就需要先做需求拆解，也就是说要去找到能分析这个需求的核心数据与能够帮助判断业务变化的一些指标，细分维度在这里的作用更多的是做需求详细的拆解，可以理解为是去做核心数据的多维度明细展示，那么目的就是从更细的维度去满足业务分析需求；   总结：先要找到能满足这个需求的核心数据，再找到核心数据分析时所需要涉及的细分维度，如图：   [图片]   第二、事件设计。可以通过这3个步骤去完成事件的结构化设计，第一个步骤是要了解产品结构，也就是先要了解分析的范围是什么，例如需要知道对哪些页面或者哪些功能有分析需求；第二步，就是要针对这些锁定的范围，去明确我们要分析用户的行为有哪些；第三步，要把这些行为，落实到具体的分析维度上；   后面会通过指标体系、分析需求、分析方法这3个角度，在去结合这三个步骤，进行事件结构化设计的详细说明。   [图片] 在介绍按照指标体系去进行结构化事件设计前，我们先看下指标体系的样例，通常会按照这几个模块去搭建指标体系，分为：概况、营销、用户价值、运营和核心功能。 1、概况可以理解日常关注的核心数据，比如：新增、启动、日活、周活、月活以及会员数据、注册数据以及使用黏性、使用时长、留存等，还包括技术、产品较为关注的稳定性数据。总的来说：就是将核心或常看的数据放在概况的大板块中。   [图片] 2、营销。通常会把广告数据，例如：广告的曝光、点击率以及广告点击排行，媒体排行、展示排行信息会放在第二个板块。 3、用户价值。通常会把新用户的次留、成本以及用户回本周期模型和生命周期模型放在用户价值模块。   4、运营。主要关注内容与转化，通常会分析内容的热度，任务的交互与会员的转化，针对会员还会分析会员新增、会员累计、会员续费等维度。                                                                                                                                                                                                                                         5、核心功能。是产品岗位较为关注的，例如：导航位、导航按钮，被用户点击的情况、使用的情况，对应核心功能，比如说搜索功能或者是注册功能，整个功能的入口、被点击的情况和转化率等相关的这些数据会放到这个板块。   从指标体系到事件设计   [图片] 如何通过指标体系去进行结构化设计？指标体系可以理解为指标与报表的一个组合，整个指标体系对应到产品结构上，可以分为对产品页面和产品功能的分析需求。下面先从产品页面的角度去进行事件设计说明： [图片]   第一步，会先锁定页面的范围，比如产品里有活动页、内容页、如果是视频App的话会有播放页，小说App会有阅读或者是听书页面。   第二步，范围圈定后就需要找分析行为，用户看到内容是否有点击行为，进入页面后的浏览行为，以及是否有分享、评论等行为。 第三步，确定了要分析的行为后，就需要进行分析维度的细化，如要分析用户浏览（浏览完成行为）内容都有哪些，还想分析用户是哪个入口（来源）进入到页面等等，这些都是针对用户行为要分析的维度； 按照这三步梳理清楚后，事件设计中与产品页面相关的事件和参数就能整理出来了，如页面范围对应的“内容页”和分析行为对应的“点击”行为，就能够清楚我们要采集的事件为“内容点击”，在根据这个事件需要分析的维度是页面名称、页面分类以及页面来源，这个事件所需要的参数也就找到了。 下图中是以内容页和活动页梳理的结构化事件样例。   [图片]   以产品功能的角度去进行事件设计说明： [图片] 同样，第一步先找到要分析哪些功能。比如：搜索、登录、注册、会员、付费、签到等，第一步找到监测功能的范围。 第二步在找行为，功能层面的行为比内容会稍微简单一些，主要是点击行为或者是完成状态。 第三步是维度，例如：搜索功能，想分析搜索入口的点击情况，搜索的关键词是什么，针对登录与充值的话，需要分析帐号登录的类型、充值的方式等等。   页面功能所产出的结构化事件样例[图片] 以搜索引擎为例：搜索引擎监测的行为是点击和完成，通常会用两个事件进行监测，搜索引擎功能在很多页面都会有入口， 通常会建议在这里增加一个参数叫搜索位置，可以辨识用户点击哪些搜索位的按钮，另外可增加参数叫用户ID，去了解具体是哪些用户进行的点击。 重点说一下功能按钮点击事件。通常情况下，会将核心要分析的功能都抽离成单独的事件进行统计。如登录、注册、付费或者是会员购买等，这些属于核心要关注的功能，并且会为这些核心功能事件单独设计要分析的参数； 但如扫一扫、加载更多以及一些Tab键，只需要监测用户点击即可 ，不需要监测功能背后的参数信息。通常会将这些点击行为放在一个事件下，定义名称叫功能按钮点击，会通过“按钮名称“与“所属页面”等参数去锁定用户点的具体按钮是哪个。   小结，通过指标体系去进行事件设计，就能够把大部分需要采集的页面与功能都能覆盖到，并且可以满足后期看数据的需求。   从分析需求到事件设计 [图片] 先引用小说行业的一个需求举例，近期上架了新书，要分析新书对用户的吸引力如何。那么第一步，就要把需求进行转义，也就是需要知道哪些数据和维度，能证明用户对新书的吸引力。   针对这个需求，分析思路是：今天新上架的小说，用户看了多少章节和时间，明天会不会继续来看，可以通过这几个维度去判断出新书吸引力。那么在落实到事件设计的三个步骤中，第一步采集的页面范围是小说页面，第二步采集的行为就是阅读，这两步对应出我们需要采集的事件就是小说阅读，第三步需要分析的维度就是阅读章节、阅读时长、小说名称以及上线日期，这些维度就可以转化成参数在事件中设计进来。 另外，一般做内容事件时，通常还会增加来源参数，比如：来源页面、来源版块、来源位置，这些参数可以帮我们定位到用户是从那些入口获取到内容的，便于后期去分析各入口的导流效率。   从分析方法到事件设计 [图片] 这部分指的是根据核心目标，在利用一套分析方法去解决问题时，如何找到解决问题环节中所需要采集的事件。   比如，目标锁定是要提升用户留存或者是提升付费转化率，那么，首先要找到不同的人群，针对人群找差异（功能使用、内容偏好的差异），找到不同的人群在功能使用、以及转化路径的差异后，在去找问题，如某一些功能对于非留存用户或者是非付费用户体验不好或推荐的内容用户不感兴趣，找到问题后，就需要进行优化，并进行验证；针对分析方法中的每个环节，其实都能对应到需要分析的事件，如找问题的环节会对入口的点击、完成的情况，内容浏览的来源等等进行事件采集，在分人群环节，会对用户的付费行为进行事件采集等等。   通过每个环节找到对应需要分析的行为后，就可以把相关信息以事件或者是参数的形式，补充到现有结构化埋点方案中了。 按照指标、需求、方法这3个角度去做了事件设计方法的介绍，总体可归纳为：有了指标体系与分析需求，整个结构化埋点方案的框架就能设计出来了。分析方法更多的作用是做分析思路上的贯穿，可以帮我们发现埋点设计中缺少或者遗漏的环节，整体上我们就可以理解为，指标体系+分析需求+分析方法这三部分的结合，才能得到一个非常贴合业务的埋点方案。 [图片]    小结：“事件采集“就是要知道谁在什么时候做了什么事情，设计思路可以分为三步，首先，了解产品结构（产品结构的范围，页面结构、功能结构）其次，了解用户行为（点击行为、完成行为、曝光行为等）最后，行为可以细分哪些维度，按照三步结构化事件就可以设计完成了。   同时，总结三个避坑的Tips： 一，需求。如果前期需求不是很明确时，可以先把这个指标体系梳理起来，比如：核心关注的指标，采集方案是可以满足暂时看数的需求，后期可以根据对分析需求的升级再去补充。 二，归类。在事件设计时要合理的进行归类，尽量用一个事件满足多个分析需求。比如，了解用户都是从哪些入口获取内容的，和内容浏览的热度排行。是可以通过一个事件来实现的，只需要通过内容名称和来源页面两个参数，就能够满足这两个需求了。 三，范围，在参数设计中两个范围需要注意，即来源和点击按钮，内容采集会涉及三个来源：来源页面、来源板块和来源位置，是为了去锁定到底内容从哪里点过来，开发也会要求将入口信息梳理清楚，从而进行埋点的开发工作。点击按钮，将按钮都归属到一个事件中，将参数设置为按钮名称，梳理出具体的按钮采集的范围给到开发，才能去进行后续的埋点。 埋点设计不是简单的事件与参数的结合，而是需要贴合业务、贴合分析场景去进行设计。   结构化事件设计完成后，下一步就是要交付给技术进行开发，下图为一个资讯行业的事件埋点模版，可以参照这个模板去进行梳理并提交给技术。友盟+开发者数据银行产品中的智能采集平台就可以按照这个模板，直接帮我们生成对应的埋点方案，并协助我们进行后续的事件管理。 [图片] 三、埋点实施 市场上主流支持的四种埋点方式，分别是代码埋点、服务端埋点、可视化埋点和全埋点。 代码埋点，支持事件与参数这种结构化的使用方式，弊端是想增加或修改事件，都需要重新发版，用户更新后才能采集。 服务端埋点，通常用于业务数据的采集，例如：付费成功、用户注册等，这个场景会选择用服务埋点进行采集。 可视化埋点和全埋点，都是解决整个App前端操作的一些点击行为，例如说某些按钮、页面，每一个点击都能监测。但差异点在于可视化埋点只能看到圈定后的数据，那么全埋点则是在圈定时，历史数据也能去追溯。 但这两个埋点的弊端是散点采集，每一个点击行为都是一个事件，在数据分析时，事件的量级会较大，不易于分析，而且它只能是取这种点击行为的事件，并不能把参数带过来，你可以理解为它就是一个纯扁平化的一个事件采集。 针对需求的不同，数据采集方式应该是结合使用的，以友盟+为例，友盟+现在支持两种埋点方式，代码埋点和可视化埋点，开发者可以结合使用，去满足事件方案的采集需求。   [图片] 四、看板校验。埋点后可通过三种方式验证，一、打印日志，开启debug去打印Log，去验证触发事件log是否有上报，这种方式需要技术来配合验证。 二、集成测试，以友盟+为例，只需要让技术注册一个测试设备，就可在你这个测试设备上去启用你的App，在去触发事件，产品、运营的同学就可直接测试埋点情况。三，也可以使用市场上智能验证的工具，以友盟+为例，可先注册设备，自动去识别整个埋点的情况，且日志是实时的，可产出事件的验证报告。 五、智能验证，可以帮您智能验证这些事件的点是否采集了，是否有遗漏，最后会定期给出体检报告，详细的明细都会有。在友盟+的智能采集页面就可以智能验证埋点，只需要注册一个测试设备，这个测试设备填加完之后会实时把客户这些埋点的数据进行验证，到底是成功还是异常，以及测试的时间是什么都会有详细的数据。 综上所述：一个公司的埋点要可见、可控、可管，如果一家公司不清楚自己的埋点结构，便是在错误的数据上长期持续经营业务，越走越错。合理的埋点方案，可以使埋点能够智能调试和验证，大幅降低埋点采集的成本，从而最终达成数据质量的根本性提升。

如果不能怎么才能引流到外卖平台上自己的店铺呢？