分享一个绿卡排期数据可视化的网站

隔壁赵大爷 发表于 2020/03/07 14:58:24
你可能没有明白我的意思。根据最新的140库存数据，2018年04月PD的EB23实际backlog大于21000，并不是...

你这里跟joanlilyqy说的是一个意思。就算我们假设那些滞后approve的140有18年总数的70%，那么也只有8400张。这是完全填不上那18000的。

Dr.FuManzhou 发表于 2020-3-7 23:18
你这里跟joanlilyqy说的是一个意思。就算我们假设那些滞后approve的140有18年总数的70%，那么也只有8400张 ...

网站给出的数字是没有问题的，我觉得你其实是在反复纠结为什么移民局2020年的backlog报告比2018年的backlog报告里多出来这么多人。这两个数据都是移民局官方给出来的，由于perm的准备时间 长，2017年和2018年的EB23 perm申请人没有来得及被统计到2018年的140 backlog报告里是唯一的解释。移民局的官方报告不会撒谎，不会故意多说也不会故意漏算任何数据。

隔壁赵大爷 发表于 2020/03/08 03:53:41
网站给出的数字是没有问题的，我觉得你其实是在反复纠结为什么移民局2020年的backlog报告比2018年的backlo...

我已经反复说了，这个差距用“没有来得及统计到2018的报告”是说不通的。
我倒觉得有可能是降级，revoke，或者其他原因造成实际的140比2020报告里approve的140少很多。

Dr.FuManzhou 发表于 2020-3-7 23:11
所以app上面的backlog是按照方法1算的？也就是完全按照20年那张表给出的140数据？

其实方法1里面也没有考 ...

是的

app里的backlog计算方式很简单
backlog(t) = backlog(t-1)+demand(t)-supply(t)
然后用19年10月的时候用backlog(t) = (cum demand from 排期到19年10月)来确定截距

我确实没看出来这么算有什么问题，可以argue的就是19年10月的时候真是排期究竟是什么

Dr.FuManzhou 发表于 2020-3-7 23:11
所以app上面的backlog是按照方法1算的？也就是完全按照20年那张表给出的140数据？

其实方法1里面也没有考 ...

方法1里面考虑了，我是把18年全部approval的140（假定均匀分布）乘以8/12 （17年10月-18年月是8个月）算进1805之前的pending pd了

Dr.FuManzhou 发表于 2020-3-8 04:44
我已经反复说了，这个差距用“没有来得及统计到2018的报告”是说不通的。
我倒觉得有可能是降级，revoke， ...

就是两点吧
1. 1805时pending的140，没有算进1805的统计里 （这个估计有8000-10000）
2. 降级然后把之前的140 revoke了，没有算进1805的统计里（这个估计也是8000-10000了）

我觉得可能是比较可能的解释了

app上为了算法自洽，没有具体对14-15年的pd进行具体操作。可以调整140:GC系数，这个系数包括revoke，升降级，换工作，回国，结婚，各种因素综合起来的。

可以看下过去几年eb23一共的绿卡发放总数，除以eb23 140总数，估计一下。

至少站在19年10月的时候，app里的eb23的backlog总数是这样计算的
- 对于中国EB2, 我们假设在2019财年结束的时候, 2015财年之前以及2015财年75%的EB2 demand已经被满足
- 对于中国EB3, 我们假设在2019财年结束的时候, 2016财年之前的EB3 demand均已经被满足
- 这是因为在19财年结束的时候中国EB2和EB3的排期分别约为2015年6月和11月（根据20财年开年数据估算得到的近似“真实”排期）.

cqluzhutou 发表于 2020-3-7 23:14
感觉数据差距还是有点太大了 接受不了啊。差这么多。

就是2点吧
1是1805的表没有统计当时pending的pd，估计有8000-10000
2是1805没有统计因为降级已经revoke的过去的140，两个一减估计也是8000-10000，差不多对上了

1的话，app是没问题的，已经考虑了
2的话，就得调app的140：GC系数了。我已经把EB3默认的140:GC系数调成1了

DanielChai 发表于 2020-3-8 05:57
方法1里面考虑了，我是把18年全部approval的140（假定均匀分布）乘以8/12 （17年10月-18年月是8个月）算 ...

明白了。所以app里backlog计算可能需要重新考虑。

我把20和18年的report进行了比较，差别很大，特别是eb3。

这里我假设18年report的数据就是取按照当月排期日取的。
比如eb2当月（2018年4月）排期是7/31/2014，18report取的就是7/31/2014-4/20/2018这段时间库存里的140。我从20年report里面取出对应时间（7/31/2014-4/20/2018）的approve的140数据进行比较。结果发现不仅eb23，eb1在20 report里面也高出不少。所以只是基于20年report对backlog进行估计，很大程度会高估backlog。

Dr.FuManzhou 发表于 2020/03/08 08:44:48
明白了。所以app里backlog计算可能需要重新考虑。

我把20和18年的report进行了比较，差别很大，特别...

我觉得EB12的误差就是递交和批准时间的6～8个月的数量差别，20年的report更准确；

EB3的额外误差就是降级revoke导致的“不准确”的重复部分，可以调整，具体怎么算可以再研究研究

joanlilyqy 发表于 2020/03/08 10:23:44
我觉得EB12的误差就是递交和批准时间的6～8个月的数量差别，20年的report更准确；

EB3的额外误差就是降级r...

你再仔细看看我的数据，只是对两个报告里面相同时间段140数量进行apple to apple的比较，所以不存在递交和批准时间差的问题。
你说20年的更准确，相反我有理由认为18年的更准确，因为20年是approve的140，你没有办法知道后来会有多少会升级降级revoke或者和row公民结婚走掉。而18年的考虑了这些。

我希望你们群里的人再好好讨论一下，不要只是想着证明app的计算没错或者20年report更准确。毕竟eb1的15%也不是个小数目。

你们自己的人也说了，官方报告不会撒谎。