Re: [Bimi] BIMI Reporting

[Tom Bartel <[e-mail]>]

Alex,

Thanks - good questions.

1) I would say logging a "display" count once per recipient, on the first
display only.
2) Reporting could report separately for list view and message view
counts.  In aggregate, anonymized, no need to relate the two
3) Display count is logged relative to display datetim, not sent datetime
or any other datetime
4) Muddies it yes, depends on the TTL I suppose.  Even with cache factor,
the signal normalizes into some baseline metric that can be taken in
context with other metrics (open and click rate) - I cant recall does the
BIMI spec advise a cache TTL at all?

I'm suggesting that an additional, discrete signal on BIMI displays
would be advantageous, alongside existing open/click data (where open
signal is subject to a lot of fuzz already, outside of Yahoo direct data
offering).

My take on BIMI is that for a sender, it's an incentive/reward to do DMARC
at full enforcement - the carrot, if you will, is that doing so provides an
advantage in the inbox - not getting to the inbox, but standing out once
there.  Big question is, does BIMI provide such a lift in practice?

Thanks,

Tom


On Fri, Apr 8, 2022 at 6:19 AM Brotman, Alex <[e-mail]>
wrote:

> Tom,
>
>
>
> I have questions about how this would be counted (“aggregate” is vague).
>
>
>
>    1. Once per recipient for the entirety of the inbox?
>    2. In the web versions for active participants, the logo shows only
>    when the message is opened.  In mobile, it shows in the list view and when
>    opened.  How is that accounted for?
>    3. Is it all messages in the inbox, even if not sent that day?
>    4. MUAs may cache these images, and then may not need to fetch them
>    on-demand.  Does this reduce the usefulness of the metric?
>
>
>
> Could not the brands utilize their own engagement metrics to determine if
> the squeeze is good?  I understand there are various groups trying to
> eliminate the Open metric, though the Click/Conversion metrics are still
> viable, yes?
>
>
>
> I’m not entirely comfortable with BIMI itself being an engagement metric.
> Is this meant to be optionally supplied by the receiver?
>
>
>
> Thanks for the feedback.
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> *From:* bimi <[e-mail]> *On Behalf Of * Tom Bartel
> *Sent:* Wednesday, April 6, 2022 7:09 PM
> *To:* [e-mail]
> *Subject:* [Bimi] BIMI Reporting
>
>
>
> After reviewing the BIMI Reporting draft:
>
>
>
> https://datatracker.ietf.org/doc/html/draft-adams-bimi-reporting
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-adams-bimi-reporting__;!!CQl3mcHX2A!R06xZr6hwSAFSpSZ8V7DUzSjr9LHJ6z5gGQTn-w0XPV_AiVHqAGmmAIvC3wly4lKgKpggrQ$>
>
>
>
>
> I think that it may be missing some useful data that would greatly benefit
> BIMI (and DMARC) adoption. Through discussions with senders interested in
> BIMI, it’s become apparent that they’ll need to measure the effectiveness
> of their deployment (to justify their spend), and I don’t think that the
> current reporting draft includes the necessary level of data.
>
>
>
> I’d suggest the addition of an aggregate count per reporting period (e.g.
> 24 hours) of BIMI logos that were displayed by the MUA. This would be in
> addition to the aggregate BIMI record evaluations already in the draft.
>
>
>
> Senders ultimately want to know if the “juice will be worth the squeeze” -
> that is, not only implementing DMARC, but the additional effort of
> implementing BIMI, too.
>
>
>
> I know that this level of reporting may happen elsewhere in the email
> pipeline than where DMARC and initial BIMI evaluation occurs, though I
> think it’s important enough to explore whether it can be added.
>
>
>
> What do folks think? Does it make sense to add this additional reporting
> signal to the BIMI Reporting draft?
>
>
>
> Tom
>
>
>


-- 
Phone: [phone]
Instagram: https://instagram.com/bartel_photo

"Life's most persistent and urgent question is, 'What are you doing for
others?'" - Martin Luther King Jr.