1286217 - Add-on recommendation engine should be trained using add-on ids instead of add-on names

Status: RESOLVED FIXED

(Cloud Services Graveyard :: Metrics: Pipeline, defect, P1)

Comment 1

[Alessio Placitelli [:Dexter]]

I've been working on that lately, and discovered quite a few interesting things.

- The id of a signed addon can be associated to different names (an addon can change its name during its lifetime).
- Unsigned addons can share the same addon id, even if they are totally different.
- The latest name for a particular, signed and reviewed addon could be retrieved using the API documented at [1] given its addon id.

[1] - http://addons-server.readthedocs.io/en/latest/topics/api/addons.html#detail

Comment 2

[Alessio Placitelli [:Dexter]]

PR: https://github.com/mozilla/telemetry-batch-view/pull/97

Comment 3

[Alessio Placitelli [:Dexter]]

Attachment: Train the model using addonIds

Comment 4

[Alessio Placitelli [:Dexter]]

Also, some notes on the data on a.m.o. There are non-publicly available addons on AMO:

- it could be because the add-on has been disabled by the developer
- it coule be because it has been rejected
- it could be because it's unlisted - the developer has submitted it to AMO for it to be signed but does not want us to distribute it, they'll handle that themselves
- it could be because the developer started the submission process but didn't finish it (and thus we have incomplete information for the addon).

In all these cases, the public unauthenticated a.m.o API won't return the addon informations.

Comment 5

[Roberto Agostino Vitillo (:rvitillo)]

Alessio, please add Comment 4 as a comment in the code.