| Age | Commit message (Collapse) | Author |
|---|
|
Purpose of this commit is to get rid of custom css code and file and use
standard bootstrap classes.
TaskID 2182610
Closes #45472
closes odoo/odoo#46948
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
This new Predictive Lead Scoring (aka PLS) replaces the stage based probability mechanism.
It uses Naive Bayes probability computation theorem.
The lead probability is now computated automatically based on multiple criteria (= frequency fields).
Some are mandatory and will always be used, some are optional and can be activated
in the settings.
- Mandatory fields :
- team_id
- stage_id
- tag_ids
- Optional fields :
- email_state (validity of the email_from field: correct / incorrect or empty if email_from is empty)
- phone_state (validity of the phone field !! not the mobile one !!: correct / incorrect or empty if phone is empty)
- country_id
- state_id
- source_id (UTM Source)
PLS uses a start date to consider only the lead created after that date to generate the frequency table
and to recompute the lead probability. This date is also configurable in the CRM settings.
Default start date is date.todays() (at module install).
The settings for PLS are NOT company related :
PLS Fields = Many2many to a model that store only the fields allowed for PLS computation.
PLS Start Date = Date
As Date and Many2many fields are not allowed for config_parameters,
Char fields are used to store the configuration
and Date and m2m fields are used to ease the configuration by the user in the config panel.
Date and m2m fields are both computed fields based on their corresponding Char fields.
Char field for Date store a strigified date.
char field for Many2many store a comma separated string which is a list of activated fields.
Each mandatory field is used in a specific way
- Team_id : the frequency table is split for every team_id, plus once for leads that don't have a team_id.
Considering Lead A from Team 1 and Lead B from Team 2.
Even if Lead A and Lead B have the exact same attributes (country, phone, email,stage, ...),
their probability will most likely not be the same.
That's because each teams compute their leads' probability based on their own won/lost leads.
- Stage_id : if no optional fields are activated and if there is no tag on the lead,
this will make PLS work quite the same way as it was working with removed stage based probability,
as only the stage will count in the computation.
But here, instead of fixing manually the probability for each stage,
this stage related probability is automatically computed based on past experience (won and lost leads).
- Tag_ids : each tag is considered separatelly, as if the lead had only one tag.
(no link between tag on same lead is made). To avoid that a tag take to much importance if his subset is too
small, we include the tag frequencies in the frequency table only if at least 50 won or lost leads had this tag.
The frequency table is a table where all won and lost leads are aggregated by fields
(mandatory or optional if activated). For each team_id / field couple, we store the number of
won and lost leads that has that fields values.
For example: Lead A is assigned to team 1 and client comes from France and has been won.
If we consider only this lead A, the frequency table will looks like :
id | variable | value | won_count | lost_count | team_id
--------+-------------+-------+-----------+------------+---------
1 country_id FR 1 0 1
To computed the probability of a lead, we get all the records for the frequency table
that match all fields (per team_id) and we compute a won score and a lost score.
The probability is computed and normalized based on those scores
- P = S(Won) / (S(Won) + S(Lost))
Considering two variables A and B :
- S(Won) ∝ P(A∩B | Won)*P(Won) = P(A|Won) * P(B|Won) * P(Won)
- S(Lost) ∝ P(A∩B | Lost)*P(Lost) = P(A|Lost) * P(B|Lost) * P(Lost)
To overcome the 'zero frequency problem',
we do not start at 0 for the won or lost count for each variable / value combination.
It suggested to start at 1, but to avoid that a small subset take to much weight compared to
a larger one, we start at 0.1.
For example :
If we start at 1 : If team 1 has few records from France,
it can get high probability to win even if every lead where lost.
variable | value | won_count | lost_count | team_id | Probability
-------------+-------+-----------+------------+---------+-------------
country_id FR 1 7 1 0.125
country_id FR 198 7306 2 0.0263
If we start at 0.1 :
variable | value | won_count | lost_count | team_id | Probability
-------------+-------+-----------+------------+---------+-------------
country_id FR 0.1 6.1 1 0.0161
country_id FR 197.1 7305.1 2 0.0263
The more we have records for each couple, the more the computation become precise.
The allow the user to decide himself which probability should be set on the lead,
a manual probabiltiy system has been implemented using 2 stored fields + 1 computed field :
- probability (stored): Probability set on the lead, can be set manually in the lead form.
- automated_probability (stored): Probability computed by PLS.
- is_automated_probability (computed): If both previous fields are equal, the probability is considered
as automatic. and each time the automated_probability is updated, the probability is aligned.
If both are not equal, the probability is considered as manual. The automated_probability is still
updated but the probability is not aligned. The user can reset the probability in automatic mode
by clicking on the estimated probability displayed in edit mode in the lead form.
probability and automated_probability are not computed fields as they are manually computed at write and create.
The computation is triggered if one of the activated frequency fields is modified or set.
To trigger also the computation when modifying the lead values on the lead views (form and kanban),
_onchange methods have been added for each frequency field.
Also, a cron has been added to run every day to rebuild the frequency table and to recompute all active
and pending leads (not won nor lost) probability.
Task ID : 1925439
PR #33589
remove rerun cron on action lost and won
|
|
that should lie in a feature branch and be reviewed. We try not
to screw the history and the branches, let us continue like
this.
Reverted commits :
189c589d762c6abdcc4b68201f1b5da182bed3dd
11b1eb1ce534dc7c4b75ee906426a65978e25d7f
f618df931a07c78ea0ad15ca0aff1b5a2a8cf002
c0ee9de360abc2f5c415c81e236b1008db1332d0
a340f0cd2aa5e8c9842e91dedc7e95981d2041ed
c6235581ef1b630f5c37bca5bfe1eb8828e22395
51cc853c6190311c5e709dbe78a708215501d17d
7a541b0d070c0b0d3df7f514b5b0387455cf44c8
3f6b92e7b5746116f0ef3a01a5a2e12566c10dd0
ecd410a3eea964ed33c6b706b0a025dfdc99f166
b6418a116d5b1b9e6763bf1886ac94423ae02b68
|
|
|
|
form views mainly.
|
|
|
|
sale_crm: moved data and demo data into
sale and sales_team module.
|
|
- moved css into sass file to standardize the process
- commented some records added in the xml file of crm.case.section that do not seem necessary
bzr revid: tde@openerp.com-20131205124749-3a1quhetgxq2d224
|
|
bzr revid: tde@openerp.com-20131205102352-ncx6whb8r0fejgcc
|
|
bzr revid: tpa@tinyerp.com-20131126064238-odztahk0kofak3vh
|
|
attach file button.
bzr revid: ima@tinyerp.com-20131114120529-5ltoe9aoglsx92vv
|
|
bzr revid: tpa@tinyerp.com-20131101090222-f0ewbmvc4kc2vqap
|
|
bzr revid: tpa@tinyerp.com-20131031071728-1n22alzz56ud0wl1
|
|
currency.
bzr revid: tpa@tinyerp.com-20130808091645-8loajee0ss41d1u4
|
|
bzr revid: tpa@tinyerp.com-20130806063416-8rrqtf3qb7j01sb2
|
|
to show tooltip as per requrement and 5 sec late,improved css to show proper cursore, improved actions & domains for proper results.
bzr revid: tpa@tinyerp.com-20130730110822-zzioh92in4azqay8
|
|
and help.
bzr revid: tpa@tinyerp.com-20130726071834-hd9qyyotf41ja57w
|
|
bzr revid: chm@openerp.com-20130524130525-1ncj630bxm0bgzfp
|
|
bzr revid: chm@openerp.com-20130503154652-r9mv3zovs8lnpj3e
|
|
bzr revid: chm@openerp.com-20130425130111-pq94g5v9o5rwyzts
|
|
bzr revid: chm@openerp.com-20130418091759-7q02xo1p4pqauowa
|
|
bzr revid: chm@openerp.com-20130417104302-g4zjti19suenxnky
|
|
bzr revid: chm@openerp.com-20130412161730-lrx5tqr6wn784glq
|
|
multi-line links when having more than 99 opportunities.
bzr revid: tde@openerp.com-20130405115903-l2ktkahovulwy9ab
|
|
remove custom CSS. kanban specific css for aliases has been moved into web_kanban.
bzr revid: tde@openerp.com-20130405110737-xhdgxodrffqtfrzp
|
|
readonly mode; improved form view of salesteams and project about aliases; improved sequence of menus to display salesteam as first menu entry.
bzr revid: tde@openerp.com-20130404115627-3vw1uv4xrmeu13k2
|
|
bzr revid: chm@openerp.com-20130325102555-5q3j1y5dapohgax5
|
|
bzr revid: chm@openerp.com-20130322160934-3mekvjm9hxaiwp4b
|
|
bzr revid: chm@openerp.com-20130305084158-8v87q3pa2tt35qhk
|
|
bzr revid: chm@openerp.com-20130304131444-lbegox654fyb85wx
|
|
bzr revid: chm@openerp.com-20130301145922-5pxvjhm0kz0tq9p0
|
|
bzr revid: chm@openerp.com-20130301144333-fzyml0e6hforfwuh
|
|
bzr revid: chm@openerp.com-20130206115736-fw3coo0u50itvjlq
|
|
bzr revid: chm@openerp.com-20130206094414-8f7kp19dam6su991
|
|
bzr revid: chm@openerp.com-20130201115642-n1wijg4exsibju84
|
|
bzr revid: chm@openerp.com-20130125110434-whqnmhrvdqj0r9gh
|
