亚马逊kindle电子书促销活动误单申诉聊天记录

我: kindle电子书促销
您现在已连接到亚马逊的 刘晓龙。
刘晓龙: 您好,目前为您解答的是亚马逊售前客服,为了给您提供更专业的服务支持,我们将帮您在线转接到kindle服务团队,随后聊天的窗口会变为灰色,请您不要关闭窗口,稍加等待,谢谢!
客户服务联盟伙伴随后将与您联系。
您现在已连接到亚马逊的 Xue。
Xue: 您好,我是亚马逊kindle客服谭雪,很高兴为您服务。^ω^
我: 您好,今天的1.99元电子书促销活动里,最后两单有疑问
Xue: 您是收到短信的通知购买的电子书是吧?
我: 是的
购买时,显示的是原价
最后一步付款时,扣的才是1.99元
买过第一本书确认过这一点后,后面的购买是直接一键下单了
Xue: 最后您的书是花费原价购买的吗?
我: 前面大概只购买了六本书,是1.99元,没有问题,但后面两本却是原价
Xue: 因为咱们的书的数量有限,您购买的原价是此书已经没有了。我帮您进行退款可以吗?
我: 这不是我的预期,能否退款吗
麻烦你了,退款吧
Xue: 没事的啊哈
您稍等
我: 感觉你们这个活动准备得不够充分
Xue: D01-6669538-9093325
D01-2528073-4094901
这两个订单吗?
我: 是这两单
促销品售完时,要有必要提示提示,不然给客户带来麻烦,对亚马逊品牌形象也不好
Xue: 已经帮您申请退款了。
我: 谢谢了
Xue: 嗯嗯,很抱歉给您带来的不便,这边我和领导反馈一下。
O(∩_∩)O还有其他的可以帮到您的吗?
我: 别的没有了,麻烦你了
Xue: 没事的哈
◕‿‿◕。)づ 有任何问题随时联系我们哦!
我: 好的,祝你周末快乐~~
Xue: 谢谢您,您也是哦~
我: 订单编号 D01-9999216-5336547
Xue: 这个是没有付款的订单
我: 这一单,我是测试一下价格的,是否需要麻烦删除一下啊
对的,只是测试一下
Xue: 嗯嗯,已经帮您取消了
我: 如果没有影响,不管也可以
嗯,谢啦
Xue: 没事的哈,我已经帮您取消了
我: 谢谢,不打扰你了~~~
Xue: 没事的哈。很高兴可以帮到您哦
感谢您对亚马逊的支持,聊天窗口即将关闭,在聊天结束后您可以继续查看聊天记录。希望我的服务能够帮助到您,感谢您对亚马逊Kindle的关注和支持。再见!
Kindle在,书未老~
【亚马逊Kindle现已开通微信公众号服务,搜索微信公众号“cn_Kindle”进行关注,我们会为您推送关于Kindle设备和电子书的最新消息,更有夜读打卡、Send to Kindle及在线客服等功能。您也可以点击公众号菜单及时获取相关信息和服务。】

 

jingdong_online_service_chat_161017

本博客正式支持HTTPS/SSL浏览(powered by Let's Encrypt)

今天起,本博客已经正式启用https/ssl,页面上链接已经更新为https链接。

使用的是Let's Encrypt提供的免费ssl证书服务。

Let's Encrypt服务优势

免费、支持多域名、国际化,并且服务商是Linux基金会成员,可信度高。

目前主流浏览器都支持该证书的,参看官方的“证书兼容列表”

负面影响评估

以GA上最近1万(准确数字是10523)次会话作样本做评估,GA只计算“人”的访问,而不计蜘蛛,这更符合现实。(可以认定,主流的搜索引擎蜘蛛应该是支持该证书的,这个影响按理可以忽略。)

按网友的经验IE6是不支持的,经过虚拟机下windows 2003里IE6测试证实了这一点(手上没带IE6的xp)。样本会话中共计10次IE6,9次IE7;由此IE6占比不到0.1%即使带上IE7,也不到0.2%. 因此旧版IE可以忽略。

Safari 4.0以下无访问。

 

Let’s Encrypt HTTPS证书申请部署与自动续期/免费ssl,nginx,centos

前言/絮叨

一年半以前曾经买过一个廉价的https/ssl证书,部署在本博客blog.path8.net上,时间大概在 2015-5-17,然而并没有正式启用,以至于过期也都没有注意。前几天想于把这个事情搞起来。以前的经验是,廉价ssl证书都是只对一个域名有效,但竟然发现Let's Encrypt的免费证书,还是多域名的。近一年的新文章里,有不少人对之大加赞扬;于是准备试试。同时也发现了腾讯云也有免费ssl证书,单域名的,免费一年,试用了一下,签发速度比较快,部署到本站上。不过还是决定使用Let's Encrypt。下面是简单记录。

CentOS + Nginx 环境下的部署

vps环境CentOS 6.x, niginx

ssh登录到服务器上操作,并且操作需要需要root权限。

1. 自动部署脚本需要epel源,如果之前没有安装先安装之 yum install epel-release

2. 在线获取签署脚本(按自己的习惯保存到合适目录)。签署脚本官方称之为客户端,有多个版本,这里使用的官方推荐的 certbot

wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto

3. 运行签署脚本。脚本里注意两人参数 -w, -d,分别是一个web目录及该目录对应的域名;多组目录就多次指定。这里只是获得证书文件,不做自动部署。(猜测是因为该脚本不支持nginx的自动部署,毕竟nginx不在centos官方源里,不同服务器上安装方式 不一样)。如下所示。

./certbot-auto certonly --webroot \
-w /var/www/html/blog.path8.net/html -d blog.path8.net \
-w /var/www/html/www.path8.net/html -d www.path8.net -d path8.net -d fengyqf.com

4. 接下来会自动通过yum安装几个依赖包,同意即可。

5. 然后是几步交互式对话:邮箱地址、同意条款、照着操作即可。因为Let's Encrypt是自动签署,速度非常快,大概整个过程只花费了两三分钟(包括交互过程里等待用户操作的时间)。

letsencrypt_req_email

交互询问邮箱地址

使用国内dns服务(如dnspod)很容易引发域名解析失败,可以用 he.net 的免费解析服务。成功后消息如文后。

在目录里 /etc/letsencrypt/live/{your.domain.ext}/ 得到四个文件:cert.pem chain.pem fullchain.pem privkey.pem  。简单理解,前两个是给Apache用的,后两个是给Nginx用的。(注意 privkey.pem 这个文件是私钥,内容千万要保密!)

事实上这四个文件是到/etc/letsencrypt/archive/{your.domain.ext}/ 下文件的符号链接。从结构上看,更新证书时,会自动更新符号链接目标。

按脚本执行的输出,运行日志记录在 Saving debug log to /var/log/letsencrypt/letsencrypt.log

下面是签署脚本成功执行后的消息。

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/blog.path8.net/fullchain.pem. Your cert will
   expire on 2017-01-14. To obtain a new or tweaked version of this
   certificate in the future, simply run certbot-auto again. To
   non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you lose your account credentials, you can recover through
   e-mails sent to f***@gmail.com.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

6. 部署证书文件到nginx上。主要是ssl_* 的行,指定为证书路径。

    server {
        listen 80;
        listen 443 ssl;
        ssl_certificate   /{your-path-to}/fullchain.pem;
        ssl_certificate_key  /{your-path-to}/privkey.pem;
        ssl_session_timeout 5m;
        ssl_protocols TLSv1;
        ssl_ciphers HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers on;
    ......
    }

7. 重新加载nginx配置 nginx -s reload  ,或者重启nginx,然后测试https访问。记得iptables放行443端口。

8. 如果需要,将http请求301重定向到https.

9. 配置定时任务以自动更新证书。重新签署证书及加载证书,将脚本加入到定时任务中,/path/to/certbot-auto renew --quiet  . 重新加载nginx配置以应用新证书的脚本如  nginx -s reload

测试ssl/https安全评级

第三方工具:https://www.ssllabs.com/ssltest/

服务器迁移至CentOS7及域名增减

2018/12/15 更新

网站服务器搬迁,从原来的centos 6升级到7,所以参考 https://certbot.eff.org/lets-encrypt/centosrhel7-nginx 的说明,centos 7下certbot安装更简单了。

yum -y install yum-utils
yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional
yum install python2-certbot-nginx

迁移原服务器上/etc/letsencrypt/下几个目录到新服务器上:

/etc/letsencrypt/accounts
/etc/letsencrypt/archive
/etc/letsencrypt/csr
/etc/letsencrypt/keys
/etc/letsencrypt/live
/etc/letsencrypt/renewa

然后让nginx正常运行。修改证书关联的域名

certbot --nginx certonly --cert-name blog.path8.net -d blog.path8.net,www.path8.net,a.path8.net,...

其中 --cert-name 参数是指定证书主域名,-d 参数是修改后的域名列表

更新证书,并在更新完成后自动执行脚本。比如分发ssl证书、重加载nginx等,可以放到crontab里实现自动化

certbot renew --deploy-hook /root/script/renew_nginx_ssl.sh

 

运营方面知识点、经验等汇总

这是和篇老旧的草稿,直接发出来算了 2024/3/11


活动,有两类,基于产品的运营活动,基于市场的活动。

主题来源不同。基于市场的,来源于当前热点,根据热点事件,与当前产品找契合点,指定活动目标,玩法。

基于产品的运营,则基于当前产品,以绩效为出发点,确定活动主题、玩法、目标。

到目标的转化

用户主要分布在哪里,使用哪些产品、功能、服务,分布比例如何;哪一块最大,在运营过程中,着重满足该部分用户的需求(挖掘需求,提升体验,为用户创造价值)


运营中,目标用户在哪里,如何到达,比例如何


计算:转化率,转化

转化率,是一个比率,而转化则包含着两个不同状态(或步骤)的变化。分别以这两个状态的统计量,求比值,得转化率。首选使用同类的统计量。流量方面的两个重要统计量为PV与UV,多数时候以UV有时更合理一些。入口而的UV,一般可以通过GA获得。

转化的第二步,进入落地页。多数时候会有多个入口进入同一个落地页,这样就不容易区分每个入口带来的UV。为计算转化率,至少有两个解决方案:1)落地页加参数,如www.example.com/event/index.htm?from=entrance_1, 每个入口链接到不同的from参数。这样可以在GA中按不同的落地页创建细分,实现区分入口。2)直接使用入口链接的点击计数,求比值,虽然是不同类的统计量,但都按该方法还是有一定参考价值的。(链接计数约等于带来的PV数)。这里还有一个可选的技术细节,计数链接使用301转向并加上一定的http过期时间,比如1小时,这样,即使用户多次点击计数链接,浏览器也不重发请求。结果是,链接点击数尽量接近于UV数。

前面讲的是入口的转化及转化率。对于一个活动内容的转化,各个不同入口带来用户的转化,也可以通过不同的from参数实现,具体是使用GA细分,计算各步的UV数。

对于最后一步的成交量,为了区分不同来源的效果,也需要记录来源时(即活动落地页)的from参数。实现的技术方案:落地页增加一段程序,将from参数的值,存储到本地cookie中,注意cookie目录,正好是本活动所在目录,层级不多不少。写cookie可以使用服务器端脚本也可以通过客户端js写。

补注,这个from参数的方案很有效,可以制定成专题活动的为开发规范。


无论什么时候都要用到的原则:

  • 不重不漏。尤其是从现象中做归纳,制定规则时。场景举例:建GA细分,根据要求,制定细分条件。

完全纯粹的小白入门第一课

【几个概念】 PV,UV,会话,着陆页,退出页,跳出率,会话时长,网页标题,主机名,网址, url,javascript, js,表单,form,表格,table,像素

【直观印象】文件大小:文件大小的单位是什么,直观的认识。

图像相关:一个像素大概是什么样/电脑屏幕尺寸通常有多大/常见的图片文件格式有哪些/通常的小图片有多大

【几个问题】

网址分哪几部分,分别是什么
常见浏览器有哪些/PC操作系统有哪些/移动操作系统有哪些

凭空想象的应用中的数据加密方案

限制单用户单位时间内最大请求频次

(如每日最多请求50次内容页){仅稍微增加了采集难度,延缓被脱库时间}

对于请求频率异常的设备,封禁若干长时间(如10分钟)

技术方案参考:

  • App在请求接口时,带上设备惟一编号、当前版本号
  • 请求异常时,将设备惟一编号列入黑名单。
  • 设备惟一编号。可以使用友盟统计的 Device Token。<Tips:惟一编号方案不要与苹果的隐私规范冲突>(注意:Android可以通过清空应用数据重置该惟一编号,iOS可通过卸载后重装重置该编号)

加密数据输,请求及响应双向加密。

至少要包括:接口名,参数名,参数值。可以考虑如下加密方案:

  • 使用AES加密算法,AES密文是二进制的,最好再做一次BASE64编码。
  • 通过接口分发密钥,密钥本身也是加密传递,真实密钥需要是经过事先约定的算法计算得到。
  • 不要通过单独的接口分发密钥,而是放在其他接口中,可以放在最低允许的版本号的接口中。响应数据中,增加适量无意义的干扰信息,增加猜解难度。
  • 密钥定期修改,在服务器端更改,App启动时加密分发给App。
  • 在做协议分析时很容易猜解接口名,因此接口名可以采用另外的密钥加密,与数据传输密钥不同。可以是硬编码到App内部的固定密钥。
  • 参数名、参数值放在一起加密,即通过GET请求字符串整体加密。
  • 服务器端响应数据,也是加密后base64编码后返回密文。
  • 固定密钥不要直接出现在App的字符串资源中。

一个接口格式参考

也可以将接口地址格式改成这个形式:

host.domain.ext/interface?model=news&action=list&class=123
host.domain.ext/interface?model=news&action=detail&class=9876

将get参数加密传输后格式示例(下面只是简单的base64,没做加密)

host.domain.ext/interface?bW9kZWw9bmV3cyZhY3Rpb249bGlzdCZjbGFzcz0xMjM
host.domain.ext/interface?bW9kZWw9bmV3cyZhY3Rpb249ZGV0YWlsJmNsYXNzPTk4NzY

甚至把interface一段也重写隐藏掉,形式如

host.domain.ext/bW9kZWw9bm3cyZhY3Rpb249bGlzdCZjbGFzcz0xMjM

对于POST请求,将post包与做类似的加密封装

其它杂项

一个接口:最低允许的版本号。作用:App启动时,检查版本号,如果App版本号过低,强制用户更新。(类似网络游戏启动时检查版本补丁的方式)

如果有在线接口文档,其地址(目录命名、目录层级等)要有一定复杂度,避免被猜到。最好是授权查阅(口令、账号、IP段等)