Closed Bug 1618064 Opened 7 months ago Closed 4 months ago

Migrate spocs from context to sponsor field

Categories

(Firefox :: New Tab Page, enhancement, P1)

enhancement

Tracking

()

VERIFIED FIXED
Firefox 78
Iteration:
78.2 - May 18 - May 31
Tracking Status
firefox78 --- verified

People

(Reporter: mathijs, Assigned: thecount, NeedInfo)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Firefox currently uses context="Sponsored by X".

Let's use sponsor="X" instead, and perform the localization of "Sponsored by" in Firefox instead of on the Proxy Server.

Priority: -- → P2
Priority: P2 → P1

Requirement: Ability to have Collections be sponsored or organic.

Assignee: sdowne → gsuntop
Iteration: 76.1 - Mar 9 - Mar 22 → 76.2 - Mar 23 - Apr 5

If the goal is to have more flexibility in the copy (eg: "organic" non-"sponsored by" collections) then I'm don't think we should bake "Sponsored by" into Firefox. That would lock us into that copy for all card grid spocs and collections.

Having that copy coming from Adzerk should give us the ability to not always say "Sponsored by....", by changing the value of the context as needed.

Am I missing something here?

Flags: needinfo?(mathijs)
Flags: needinfo?(tkanhema)

Every data entry step contains the possibility of human error, so we should avoid a situation where ad-ops needs to paste (or worse, type) localized strings into every creative that are not specific to the creative.

To meet the requirement that collections can be organic or sponsored, we could put an is_organic true/false flag in AdZerk. Firefox could use that to display the "Sponsored by" text or not. This has the benefit that all UI copy is in one place, and we don't need to build localization logic into multiple systems.

If in the future we need to have the option to render custom strings here, then we could have Firefox default to "Sponsored by" and override it if the AdZerk value is non-empty.

Flags: needinfo?(mathijs)
Iteration: 76.2 - Mar 23 - Apr 5 → 77.1 - Apr 6 - Apr 19

Ok, that sounds reasonable. Just to recap the proposed logic:

  • If context has a value then use it as-is (eg: if context contains Brought to you by Mozilla just show that)
  • If context is null, undefined, or an empty string then we will show Sponsored by + sponsor in the client

If we do this then we should have no need for an is_organic boolean, right?

Flags: needinfo?(mathijs)

Tawanda (/Tyler) - do we need the ability to have organic recs without any "Sponsored by" or context string for Collections? Ie just a Title of the Collection. (Thinking about if we did a Pocket-curated Collection - what would we want it to say there if anything?)

Flags: needinfo?(tmiller)

(In reply to Jessilyn Davis from comment #5)

Tawanda (/Tyler) - do we need the ability to have organic recs without any "Sponsored by" or context string for Collections? Ie just a Title of the Collection. (Thinking about if we did a Pocket-curated Collection - what would we want it to say there if anything?)

We do want the ability to show the card collection without sponsored text, though I don't know if that is the same component as a card collection with a sponsor.

Flags: needinfo?(tmiller)

We do want the ability to show the card collection without sponsored text, though I don't know if that is the same component as a card collection with a sponsor.

In the logic outlined above, that would just mean setting context to whatever we want to show.

Will there be a scenario where there wouldn't want to be anything there? (ie, would someone want to hack context by putting in a space so that it wouldn't be null but wouldn't show any filler text? If so, does that mean there'd be an extra space with only the space showing?)

  1. Good question Jess. We could solve that by having a special token like "none" that would return an empty string. Not setting the value in AdZerk would result in dropping the field altogether.
  2. We can't use context for this purpose, because that is currently being used by Firefox clients and we need to keep it around for a while to support backwards compatibility. We could call the new field sponsored_by_override.

Proposed logic:

  • If sponsored_by_override has a value then use it as-is (eg: if sponsored_by_override is "Brought to you by Mozilla", then just show that)
  • If sponsored_by_override is an empty string then don't show the label.
  • If sponsored_by_override is missing, then we will show "Sponsored by " + sponsor in the client.
Flags: needinfo?(mathijs)
Iteration: 77.1 - Apr 6 - Apr 19 → 77.2 - Apr 20 - May 3
Assignee: gsuntop → sdowne
Iteration: 77.2 - Apr 20 - May 3 → 78.1 - May 4 - May 17

Steps to test:

  1. Set browser.newtabpage.activity-stream.discoverystream.endpoints to http,https
  2. Set spocs-endpoint to https://e5e8374d-fffa-4a77-a604-31603852b6fd.mock.pstmn.io/spocs/context
  3. Ensure you can see spocs.

Expected:

First spoc should say "Spoc 1 override" <- this is the override field.
Second spoc should say nothing. <- this is the override field with an empty string.
Third spoc should say "Sponsored by spoc 3" <- this is sponsor and fluent translating it.
Fourth spoc should say "Sponsored by spoc 4 ..." <- this is backwards comp for context.

Depends on: 1637020
Iteration: 78.1 - May 4 - May 17 → 78.2 - May 18 - May 31
Pushed by sdowne@getpocket.com:
https://hg.mozilla.org/integration/autoland/rev/3d91ba9e1d25
Moving sponsored by field into fluent with override for specific content. r=gvn,fluent-reviewers,flod
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 78

I have verified this enhancement using the steps from comment 11 and I can confirm the following:

  • The "Spoc 1 override" label is displayed on the first SPOC.
  • There is no label displayed on the second SPOC.
  • The "Sponsored by spoc 3" label is displayed on the third SPOC.
  • The "Sponsored by spoc 4 context" label is displayed on the fourth SPOC.

Verified using the latest Firefox Nightly (78.0a1 Build ID - 20200521093657) installed on Windows 10 x64, Mac 10.15.4, and Ubuntu 18.04 x64.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.