Segmentation Problem: View Count/Referrer Conflict

[jeffersonrabb]

For segments with a referrer defined, Articles Read and Articles Read In Session have no meaning. The segment applies only to the page viewed by clicking a link on the referrer site. This raises a few questions:

1) Should the referrer be persisted? In other words, if a user clicks a link in a tweet, arrives at the site and navigates to a different post should they still be considered to be in the segment? If so, for how long?

2) If the answer is no, we should adjust the UI to indicate this. This could be done by force-setting Articles Read and Articles Read In Session fields to "1" and disabling the inputs when a referrer is set. It also could be done by hiding these fields.

3) An alternate, more complex approach would be to define segment "types." If a segment is of type "referrer" then the visible fields change.

4) Changes should be made to the segmentation logic in newspack-popups to ensure segments with a referrer and > 1 viewed values are handled.

@thomasguillot I'd be interested to hear your preferred approach.

[thomasguillot]

I’d be tempted to answer this with a “no” and I like the (3) approach. We could have some sort of Modal to select the type of segment before creating it — similar to “Add New Prompt”

[dkoo]

An idea I was toying with mentally was grouping the different sets of options into "criteria" that you add or remove from a segment. For example (the criteria headings are just off the top of my head):

• Reader Engagement
  • Favorite category
  • Articles read in past 30 days (min, max)
  • Articles read in current session (min, max)
  • For these two, would love it if we could use a control like https://material-ui.com/components/slider/#range-slider instead of number inputs, but that would require that we limit the max (if anything less than "any") to a reasonable maximum.
• Reader Activity
  • Newsletter Subscription (known subscriber, known non-subscriber, unknown, everyone)
  • Donation (known donor, known non-donor, unknown, everyone)
  • Brian had mentioned that there are actually three statuses for each of these as outlined above, but I struggle to understand the technical difference between "unknown" status and "known non-subscriber/donor".
• Referrer Source
  • Sources to match
  • Sources to exclude

So once you have the options grouped into the above criteria, you can enable or disable each set. New segments start out with no criteria enabled. Enabling the "Referrer Source" set of options will automatically grey out and disable the "Reader Engagement" options if enabled, and vice versa. If you save the segment while one of the sets is greyed out, those option settings are discarded (or saved in a disabled state so they can be retrieved later, but this is maybe not necessary). Reader Activity options don't conflict with either other set, so you should be able to enable those without affecting the others.

[dkoo]

For segments with a referrer defined, Articles Read and Articles Read In Session have no meaning.

Is this actually true for Articles Read, though? What if a reader clicks through to the site from multiple tweets over a 30 day period? A segment with an Articles Read range and Twitter referrer URLs would capture those repeat Twitter readers each time they click through. A very specific segmentation, but maybe useful if you want to talk to those people who interact with the site mainly via social media?

[brianboyer]

FWIW, it would make sense to me if referrer was implemented at the campaign level, similar to how someone can choose to target a campaign to certain categories of content.

[jeffersonrabb]

FWIW, it would make sense to me if referrer was implemented at the campaign level, similar to how someone can choose to target a campaign to certain categories of content.

I would have to disagree with this for the following reason: The intention is that all active prompts belong to a single campaign - there are edge cases where this may not be true, but we're providing "Activate All" UI which publishes all prompts within a single campaign and unpublishes all others. Given this, if we assigned referrer at the campaign level there would be no way to have one prompt for Twitter inbound and another for everyone else without activating prompts from multiple campaigns, which would be an anti-pattern.

[adekbadek]

For segments with a referrer defined, Articles Read and Articles Read In Session have no meaning. The segment applies only to the page viewed by clicking a link on the referrer site.

I'd like to clarify if I understand this correctly. As a user, I might want to target frequent readers who visited by clicking a link from facebook. I'd set up a segment with both referrer and articles read. When a frequent reader then clicks a link to my site on facebook, they'd still be identified as the frequent reader, and now additionally as coming from facebook. They will not match the segment on next page load (since the referrer applies only to initial page load), but that does not matter for my messaging. This seems to me a valid scenario, what am I missing?

cc @jeffersonrabb @dkoo

[dkoo]

@adekbadek: Thinking about this more, I suppose you're right. A reader could be referred from an external source but be a returning visitor with articles read in the past 30 days, or enough articles read to have a favorite category. It might even be possible (if unlikely) for a reader to have articles read in the past 45 minutes but still land on another page from an external referrer. Maybe they're reading the publisher's Twitter feed and hit a few articles from the feed in a single session.

So maybe disabling the fields in #862 is unnecessary? However, it might still be worth warning that a segment with, for example, both min. articles read in session and referrer matching would likely be an extremely small segment of readers.

[adekbadek]

However, it might still be worth warning that a segment with, for example, both min. articles read in session and referrer matching would likely be an extremely small segment of readers.

I'd rather propose to add a notice saying that this condition applies only to the first page visited in a session, WDYT?

[dkoo]

I'd rather propose to add a notice saying that this condition applies only to the first page visited in a session, WDYT?

That sounds fine to me. So I'll back off the prescriptive toggling/disabling of fields approach in #862. Will update that PR to reflect this decision.

[matticbot]

:tada: This issue has been resolved in version 1.37.0-alpha.1 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket:

[matticbot]

:tada: This issue has been resolved in version 1.37.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: