pdd精灵
2019-12-05 08:42:39 Itwdd 阅读数 16

pdd精灵

免费功能:查排名,开团提醒,一键单号发货
vip价格(元):季度卡80、月卡40、半年卡150、年卡280、永久卡600

2018.5.18 v7.1更新:

1.新增:【关键词排名】修复“智能分词”,且“查排名”可查看搜索热度,方便找重点词;

2.新增:【关键词排名】【直通车管理】“查排名”可开关模拟千人千面;

3.新增:【关键词排名】“历史记录”单个词可删除;

4.新增:【开团提醒】表格内新增“备注”显示,方便区分订单;

5.优化:【虚假救星】更名为【虚假预防】;

6.优化:7.0部分客户闪退问题等其他细节;

7.优化:优化了升级客户端,以后升级更方便些;

(不限店铺,不限电脑)功能列表:

1.全网类目人气热词,为标题优化和开车提供数据支撑;

2.下拉框找词,为新品宝贝找长尾词,刚开车找长尾词;

3.开团提醒,支持多店铺,开团语音,成团语音,即将失效订单语音,掌握实时订单情况;同时开启了虚假预警,退款提醒;

4.shuadan助手(全网首创),批量备注功能,可备注开团中、已成团订单,100%零遗漏,支持群店,自动识别店铺,自动生成报表,sd效率提升70%以上;

5.关键词排名,一键智能分词,系统自动匹配相关词;历史记录可以更好的观察排名趋势,对优化结果也利于您总结经验;

6.类目排名,一键查询各分类下的排名,支持批量,且记录历史排名,同样方便大家分析数据;

7.活动排名,我们是支持最多的活动类型的查询软件;

8.订单管理 批量发货,一键kongbao发货功能,效率提高80%,卖家朋友的最喜欢的功能;

9.虚假救星(全网首创),实时提前提醒虚假罚款,可以提前提醒,让卖家有时间去修改检查物流,是避免罚款的最后一道防线,是软件中很核心的一个功能;还有批量查快递功能等;

10.退款提醒,遇到骗子,或者发货前就提醒,可以及时处理退款,又提高店铺处理速度,一定程度上提高了店铺权重;

11.对手监控,知己知彼,学习爆款是怎样炼成的,学习优秀的对手是走向爆款的最快捷的道路,也是数据分析中不可少的功能;

12.对手类目,新手或者在发布一些比较模糊的商品,可以学习对手是发布在什么类目,如果放错类目将很难获取到流量,这个功能也显得很重要;

13.直通车管理,一目了然各种数据表现,全网独有的质量分功能可以更好的得到数据反馈,实时查排名配合便捷的调价功能,可以快速车位;独有的批量添加词功能,节省了你的宝贵时间;优化直通车数据更加得心应手,助力爆款更科学和简单;

14.店铺数据,昨日宝贝访客,转化率等,直接做成表格,方便跟踪数据走势,提高了运营人员的效率;

15.【降权查询】功能,全网首创!!快速查询商品是否降权;

16.【同行出价】功能,可查询同行开车数据,知己知彼,可分析方向,参考优秀主图和商品,作用大;

低门槛,不设置普通vip和超级vip,一视同仁,1天只要几毛钱,免费试用,自信与诚信同在!市面上性价比很高的软件,致力帮助更多的卖家朋友们。

更多功能正在加入,走在便捷、创新的前列!

丁丁软件出品

2019-08-13 21:11:02 dpengwang 阅读数 104

小多想在美化一下自己的庄园。他的庄园毗邻一条小河,他希望在河边种一排树,共 M 棵。小多采购了 N 个品种的树,每个品种的数量是 Ai (树的总数量恰好为 M)。但是他希望任意两棵相邻的树不是同一品种的。小多请你帮忙设计一种满足要求的种树方案。

输入描述:
第一行包含一个正整数 N,表示树的品种数量。
第二行包含 N 个正整数,第 i (1 <= i <= N) 个数表示第 i 个品种的树的数量。
数据范围:
1 <= N <= 1000
1 <= M <= 2000

输出描述:
输出一行,包含 M 个正整数,分别表示第 i 棵树的品种编号 (品种编号从1到 N)。若存在多种可行方案,则输出字典序最小的方案。若不存在满足条件的方案,则输出"-"。

输入例子1:
3
4 2 1

输出例子1:
1 2 1 2 1 3 1

首先判断能否种树:
如果M是偶数,那么如果有某个种类的数量大于M//2, 那么不能种;
如果M是奇数,那么如果有某个种类的数量大于(M+1)//2 , 那么不能种;
接着如何种树:
每次种树之前,先判断剩下的树种有没有数量等于所有树数量一半((M+1)//2)的种类,如果有, 则先种该树,否则,总小到大遍历,找到第一棵可以种的树(要与上一课树不同)

while True:
    try:
        _ = int(input().strip())
        array = list(map(int, input().split()))
        n = sum(array)
        maxer = max(array)
        if n % 2 == 1 and maxer > (n + 1) // 2 or n % 2 == 0 and maxer > n // 2:
            print("-")
        else:
            result = []
            while (n):
                maxer = 0
                index = -1
                for i in range(len(array)):
                    if array[i] > maxer:
                        maxer = array[i]
                        index = i
                if maxer > n / 2:
                    result.append(index + 1)
                    array[index] -= 1
                else:
                    for i in range(len(array)):
                        if array[i] > 0 and (len(result) == 0 or len(result) and i + 1 != result[-1]) :
                            result.append(i + 1)
                            array[i] -= 1
                            break
                        else:
                            continue
                n -= 1
            result = list(map(str, result))
            print(" ".join(result))
    except:
        break
2019-11-14 21:32:40 weixin_45625493 阅读数 13

为了准备实习面试三天速成了SQL(正如我所说,我的动力来源之一是DDL),正好收到了Pdd笔试,别人告诉我说一般是三道SQL一道ABtest一道业务题。我想着正好我速成了耶!结果,恩,原来我只是速成了基础。

这边整理一下题目重新做一遍。

选择题

  1. 两个变量之间存在多重共线性错误的有:
    A. 变量重要性与专家意见不符(题没记全。。)
    B. 回归系数与实际不符
    C. 相关系数大于等于0.85
    D. 方差膨胀因子小于5

  2. 2,4,18,86,()

  3. 需要统计平台数以亿计消费者的平均客单价,为减少计算量快速出结果,采用抽样的方法。以下哪种方法最合适()
    A. 系统抽样。随机排序,隔一定数量抽取一个
    B. 按金额分段抽取
    C. 放回随机
    D. 不放回随机

  4. 设随机变量X在区间[1,8]上均匀分布。求对X进行的三次独立观测中,至少两次大于3的概率是?
    解:f(x)=1/7,x∈[1,8]
    P(X>3)=∫(上限为8,下限为3)1/7dx
    =5/7
    三次独立观测满足二项分布B~(3,5/7)
    至少有两次

SQL

  1. 计算某网站每日访客中的新用户的占比。首日访问为新用户,之后日期访问为老用户。
  2. 有一用户登录日志表,记录用户2018年内每天的登录情况。请计算每个用连续登陆的最长天数。
    问答
    大促活动结束后,需要进行一次复盘分析,请问你将如何开展?
    找到了一些文章,先记录一下,会单独总结一下。
    大促复盘后,我发现了数据分析后的秘密
    电商大促如何做好活动复盘
    “大促”背后的秘密?手把手教你做活动数据分析
    电商大促活动总结和复盘全套模板
    那些活动复盘要看的数据指标
2019-11-05 16:28:08 weixin_40161962 阅读数 10
import java.util.Scanner;
public class Main {
    private static boolean flag  = false;
    public static void main(String[] args) {
        Scanner in = new Scanner(System.in);
        int n = in.nextInt();
        int[] A = new int[n + 1];
        int sum = 0;
        A[0] = 0;
        int i = 1;
        while (in.hasNextInt()) {//注意while处理多个case              int a = in.nextInt();
            int b = in.nextInt();
            A[i++] = b;
            sum += b;
        }
        int[] res = new int[sum];
        backtrace(A, res, 0, sum);
        if(flag == false){
            System.out.println("-");
        }else{
            for(int j = 0; j < res.length; j++){
                System.out.print(res[j]+" ");
            }
        }
            
    }
    public static void backtrace(int[] A, int[] res, int index, int n){
        if(index == n){
            flag = true;
            return;
        }
        if(flag == false){
            for(int i = 0; i < A.length; i++){
                if(A[i] != 0){
                    if(index == 0 || res[index - 1] != i){
                        res[index++] = i;
                        A[i]--;                   
                        backtrace(A, res, index, n);
                        if(flag == true){
                            break;
                        }
                        index--;
                        A[i]++;
                    }
                }
            }
        }
    } 
}

最后一个case超时,待改进

2019-02-27 15:55:20 KerryZhu 阅读数 561

如果不了解故事背景的,可以先看:

质量警钟:拼多多100无门槛券随便领,官方紧急下架

 

DevOps技术发达的今天,PDD薅羊毛事件本不应该发生。

  • 原本就不该出现这种无门槛的优惠券(等同于送钱),就算一定要发这张优惠券,应该发给特定用户目标群,不该让同一个人能薅几十万羊毛;

  • 即使业务需求没错,而是开发代码写错,测试也该发现;

  • 即使测试没发现,上线后半夜突然爆发的流量也该被系统运维监控到;

  • 即使系统运维监控不到,旁路实时资金风控系统也该检测到;

  • 即使这些没有监控到,是不是运维值班人员人肉也该发现,不至于9小时后才被制止。

 

这种业务需求的实现,不仅需要开发(Dev)按业务需求实现与验证,而且在运维(Ops)那边应该有相应的防范机制和技术保障措施的。而昨晚PDD薅羊毛事件显示PDD没有这样的验证、防范机制,所以羊毛党能直接用猫池+脚本API进行批量自动操作,薅羊毛才能薅得这么快、这么多。

 

这其实不是一个问题,而是显示PDD在研发、发布、运维和风控方面的一系列问题,如需求评审和系统业务测试不到位、系统CI/CD机制有漏洞、缺乏良好的业务风险校验或控制环节、运维监控形同虚设,甚至人工监控可能也缺失。

 

 1. 从需求上看

这种无门槛的百元优惠券就不应该出现!如果为了发展新用户,送无门槛优惠券也是电商常用方法,但应该经过公司某部门审批、在系统内有限制(单张不得高于30元,这叫内禀业务规则),而且还有其它业务条件,如一人只能领一张,而且不能应用于虚拟物品(如电话费、Q币等)的消费。如果没有这些限制,就自然给羊毛党有可乘之机,他们自然就购买那些最具流通性、实时交易、实时变现的虚拟产品(Q币、话费等),例如Q币实时充值、实时7折优惠售出,很容易变现,况且很多羊毛党都有专门的洗白通道。

这类需求错误,产品经理或业务人员就不应该犯,即使犯了,开发和测试对需求的评审、实现和验证过程中也该发现。

 

 2. 从研发上看

开发实现这类“无门槛的百元优惠券”用户故事时,也会想想哪类用户角色会使用这类优惠券,并在代码中加以限制。如果是开发失误了,测试会发现。测试用例都是有前置条件的,或测试人员进行手工测试,也往往需要扮演不同角色进行业务功能的测试,自然也能发现这类问题。

如果是测试人员配置错了测试券,就自动上线了,那说明持续集成/持续交付(CI/CD)缺乏自动验证,或者说缺少一个Staging环境(相当于Beta环境)来验证新上线的特性。即使直接上到产品线,也需要在部署完之后进行快速测试。即使没有做部署验证,如果采用灰度发布,即使出问题,影响范围小,造成的损失也不会这么大。

 

3. 从运维上看

即使需求或研发某个环节出错了,错误的特性也上线了,在运维端也应该被监控系统发现。如发现各种异常:

  • 在凌晨3点到6点时,系统有大量访问,流量快速上升…

  • 不同账号出现大量同一收货手机号、同一收货地址、同一行为、同一IP地址、同一支付ID等;

  • 某一虚拟商品被抢购,销量暴增;

  • 某一类优惠券的使用量在快速增加…

  • ……

这类异常数据或问题自然是不正常的事,会触发内部报警机制,运维人员在第一时间就能处理。但是这些监控策略或机制也没有,据说是研发人员上班看到并发异常的日志才发现的

 

4. 题外话

某公众号谈到PDD 研发和运维团队不乐意修内功,而喜欢秀外功,因为内功不容易被看到、不容易体现KPI,而外功容易,甚至很多运营恨不得管羊毛党叫爸爸,跪求他们来薅,反正羊毛薅完,GMV是特别好看,亏损是公司的,绩效奖金和升职加薪是自己的,所以何苦来哉?

从此想到软件测试。真正做好测试分析、测试设计的业务测试,其实对公司很有价值,但不容易讲故事、不容易写入KPI,在外面找好的工作机会还少。这样许多测试人喜欢搞自动化测试、重复造轮子,测试效果却一般,但这毕竟容易讲故事、容易写入KPI,即使成本很大,对公司不一定是好事,但对测试工程师是好事,既有好的绩效,又提高了自己的能力,出去找工作更有竞争力。

 

没有更多推荐了,返回首页