电子渠道用户选择网点自寄(非微信支付分)订单来源选?(40分)

来源：蜘蛛抓取(WebSpider) 时间：2022-05-26 09:24 标签： 微信公众号推广

1.请问您平时一周做几次地铁呢？

2.首选买票方式是什么呢？（买票 一卡通 NFC微信 支付宝 地铁app）次选方式呢？

3.坐陌生地铁线路前会选择哪一种途径来规划呢？

 4.坐地铁时很不巧遇到车厢非常拥挤。这时是什么感受呢？

（请用数字评分：0代表无所谓——10代表很不爽）

5.地铁出行时，会给等地铁的时间/换乘二次等待 预留时间吗？

6.有遇到过刚下站台，地铁开走的情况吗？

如果有，这时是什么感受呢？

（请用数字评分：0代表没感觉——10代表烦躁）

7.乘车层能看到下一列地铁多长时间到，下下列多长时间到，觉得这个信息对你有帮助吗？（如果有，请描述一下是什么层面的帮助）

8.若是在地铁口或安检处能看到上述列车到站信息，觉得对您有帮助吗？

9.有没有在末班地铁时间坐地铁，担心万一赶不上或者换乘不上的经历?

10.对夏天地铁的空调温度满意吗？

（请用数字评分：0代表不满意——10代表满意）

 用户调研特别篇：

特别地，在访谈过程中遇到一位乘客并与她进行了几十分钟的交流，并记录。
用户：女性，40多岁，使用支付宝扫码买地铁票，经常坐地铁。使用苹果自带地图导航规划地铁出行。
场景：23：11（4号线开往航天新城方向的末班车到达时刻），末班车刚关门开走，她没上去，只能选择换乘2号线坐3站到大明宫西再打车。
Q：之前有没有赶末班车的经历？
A：有，且有时能赶上，有时赶不上，即使快到时间也会下来试一下。有时白跑一趟很失望。
Q：在地铁口或安检层能看到地铁到站信息，有帮助吗？
Q: 到站时间信息的精度多少合适呢？
A：分钟即可，自己一般也会预留一两分钟时间作为缓冲。自述：因工作等原因需要经常坐长距离的地铁，在用苹果手机自带的地图导航过程中，认为导航在换乘环节没有规划时间和给予帮助。（去接人过程中因为10分钟的换乘用时导致迟到）强调自己40多岁岁数也不大，但是搞不懂太复杂的各种软件，父母辈坐地铁会更困难。认为查到站点末班时间不够准确。（实际上的末班车时间是准确的，误差不会超过1分种以上）

关于本次访谈：内容总结：1特别注意该女士的访谈场景，各项需求是在刚经历错过末班车后提出的。2该女士不善于使用流行的互联网工具，如高德地图在出行规划中会提示换乘时间，末班车时间在各种导航地图及微信支付宝等都能查到。3该女士时间管理能力较弱。

方法总结：二十多分钟左右的时间没有挖掘到全面的信息，没有做常规的问卷问题调查。且一开始在换乘走路的过程中不方便记录，
在坐上地铁后拥有稳定环境之后还是没有记录，导致复盘的难度提升，不应该在不重要的问题（查不到末班时间）耽误太长的时间。
没有留联系方式，无法做长期的跟踪调研。

关于微信地铁乘车码功能优化的用户调研总结

1.大部分用户都会选择支付宝或微信来作为自己地铁出行的购票手段。

2.几乎所有用户都不会使用微信或支付宝提供的地铁线路图去规划陌生出行线路，同时也能得出用户使用乘车码的场景仅限于到达地铁站到进站前的时间。

3.用户大都喜好宽敞舒适的乘车环境，但并不代表用户会因拥挤放弃地铁出行。

4.用户对地铁车厢温度满意程度较高。

5.几乎所有用户都希望得到列车到站信息的反馈，有一部分希望能更早的得到到站信息。

注：因能力范围、客观条件等各种原因限制，此次用户调研并不重在统计用户数据，主要对大众乘坐地铁的体验进行一个摸底。对产品后续的发展提供一些指导性的帮助。

通过调研的过程，能够基本描述场景、需求与用户角色。通过以下几个用户画像来描述产品列车到站信息展示功能的目标用户。

小A是一名善于规划时间的大学学生，远远看到人行横道绿灯快结束时，会快步跟上。坐地铁下楼乘车时，若是听到“滴滴”的即将关门提示音也会尽量赶上。节约时间的同时，让他获得了一种“赚到了”的成就感。

小B是一位步入职场不久的大城市白领，由于家和公司很远，每天早上不得不坐早班地铁通勤，但是早六点的地铁间隔很长，有时下到站台了却发现还要等10分钟，此时他心想：“早知如此我就在地铁口买个早点吃了。”

整个用户调研的过程一直伴随着我的大量思考，从问题提出到问卷设计到访谈过程到结果整理，每一阶段都有不断涌现的想法和新的理解，简单罗列几个问题记录曾经的思考结果。

1在问问题三时后来有考虑要不要对首选微信/支付宝的用户说，除过这两种后会选择哪一种购票方式（这两种属于同类），但是还是决定不这样问好，因为原问法可以观察到用户对于原支付方式的黏性，他们是只用微信、支付宝呢，还是用哪个对于他们来说没有区别，只是喜欢他们所共同具有的特性即快捷方便的购票方式。

2为什么不通过让用户填写问卷的方式：（1）问卷填写的答案质量不高。（2）没有好的渠道覆盖目标群体，身边都是学生，群体单一。（3）问卷无法做跟进的调研，无法获得即时反馈以及提出拓展问题。

3特殊线路问题：并行线路问题（上海3、4号线）查询拥挤度来决定是否等下一班另一线路地铁（时间成本预期 舒适提升程度预期）（成都1号线）

分叉线路问题（成都1号线、上海10号线4个终点站、上海11、5）提前得知哪一班，节省时间成本。

项目里对接微信特约商户支付差不多是一年前了吧，很多东西都忘了，刚好今天在新项目里调试这一块，然后掉坑里了。

比较久的一些坑以后再说，就先记录一下今天的坑吧。

这里以php，微信最新的sdk为例。

微信支付开发文档（境内）分普通商户版、服务商版、银行服务商版，这里只讨论前两个，两者区别的话就是在接口上的一些参数不同，比如服务商版在调用统一支付API的时候需要填写sub_app_id，sub_mch_id之类的，这没什么，加上就是了，如果自己从0开始写的话那没什么，如果使用微信的SDK的话就要注意了，普通商户版和服务商版提供的SDK同样都是普通商户版的SDK，这就意味着，如果你要对接服务商版，缺失的参数以及对应的设置方法获取方法需要你自己在SDK里添加好，否则不成功，比如前面提到的sub_app_id，sub_mch_id。

//异步通知url未设置，则使用配置文件中的url

这是微信支付SDK中统一下单接口方法，其中$inputObj在普通商户下这样用是没问题的，但是到了服务商版本，有了如下区别：

先来看看服务商支付所需要的参数（摘自）：

服务商商户的APPID
微信分配的子商户公众账号ID，如需在支付完成后获取sub_openid则此参数必传。
微信支付分配的子商户号
终端设备号(门店号或收银设备ID)，注意：PC网页或JSAPI支付请传"WEB"
Y，传入Y时，支付成功消息和支付详情页将出现开票入口。需要在微信支付商户平台或微信公众平台开通电子发票功能，传此字段才可生效
随机字符串，不长于32位。推荐
腾讯充值中心-QQ会员充值

商品描述交易字段格式根据不同的应用场景建议按照以下格式上传：

（1）PC网站——传入浏览器打开的网站主页title名-实际商品名称，例如：腾讯充值中心-QQ会员充值；

（2） 公众号——传入公众号名称-实际商品名称，例如：腾讯形象店- image-QQ公仔；

（3） H5——应用在浏览器网页上的场景，传入浏览器打开的移动网页的主页title名-实际商品名称，例如：腾讯充值中心-QQ会员充值；

（4） 线下门店——门店品牌名-城市分店名-实际商品名称，例如： image形象店-深圳腾大- QQ公仔）

（5） APP——需传入应用市场上的APP名字-实际商品名称，天天爱消除-游戏充值。

商品详细描述，对于使用单品优惠的商户，改字段必须按照规范上传，详见
附加数据，在查询API和支付通知中原样返回，该字段主要用于商户携带订单的自定义数据
商户系统内部订单号，要求32个字符内，只能是数字、大小写字母_-|*且在同一个商户号下唯一。详见
符合ISO 4217标准的三位字母代码，默认人民币：CNY，其他值列表详见
订单总金额，只能为整数，详见
异步接收微信支付结果通知的回调地址，通知url必须为外网可访问的url，不能携带参数。
trade_type=NATIVE时，此参数必传。此参数为二维码中包含的商品ID，商户自行定义。
上传此参数no_credit--可限制用户不能使用信用卡支付
trade_type=JSAPI时（即JSAPI支付），此参数必传，此参数为微信用户在商户对应appid下的唯一标识。openid如何获取，可参考【】。企业号请使用【】获取企业号内成员userid，再调用【】进行转换
Y，传入Y时，支付成功消息和支付详情页将出现开票入口。需要在微信支付商户平台或微信公众平台开通电子发票功能，传此字段才可生效

该字段常用于线下活动时的场景信息上报，支持上报实际门店信息，商户也可以按需求自己上报相关信息。该字段为JSON对象数据，对象格式为{"store_info":{"id": "门店ID","name": "名称","area_code": "编码","address": "地址" }} ，字段详细说明请点击行前的+展开

按照SDK的写法，这三个值应该有对应的设置方法和读取方法：

然而，并没有。甚至我在整个SDK里搜索sub这三个字母都无结果。所以这里需要我们自己去添加对应的方法。emmmmmm这算是个小坑吧，自己改改就完。

然后说回这仨值，这仨值是必填！必填！必填！否则报错，而文档里sub_app_id、sub_openid的必填属性为否。

嗯，好，以上的都没啥问题了，后边签名又过不去了，看（服务商版）：

嗯，没毛病，不过怎么看着就面熟呢？再看看：

这特么不一个样么？不都是按照ASCII码从小到大排序拼接然后拼上商户密钥key最后md5运算转换大写么？为什么我就是不通过？

那么，坑来了，这个商户密钥key，服务商版的需要用服务商的商户密钥key，而不是子商户的。

好的，换上了服务商的key，通过了，也获取到了前端调起支付需要的xml数据了，然后兴冲冲拿着这些数据去进行签名处理好发给前端调起支付了，然后前端也确实得到了timeStamp、nonceStr、package、signType、paySign这五个参数（以小程序为例），然后前端也兴冲冲的拿起手机扫码付款了，这时候突然手机上一个弹窗：支付签名验证失败。然后一下子就从天上掉下来了，为什么？不是签名通过了么？参数也都全啊？怎么就又签名失败了？

于是跑回去各种检查各种尝试，然后对比检查到了签名这一块：appid、timeStamp、nonceStr、package、signType都设置了啊，package也按要求prepay_id=的方式填写了啊，到底怎么回事？恭喜又踩坑了，这里的appid不能使用服务商的，而是使用子商户的，也就是sub_app_id。

改完参数后，emmmmmmm成了。

以上是付款遇到的坑，emmmmm还有退款，年代久远都忘了，等新项目对接到了再说吧，又得头疼一阵子。

我要回帖

更多关于 微信公众号推广 的文章

 

随机推荐