Subject: [Bimi] BIMI Reporting

From: Tom Bartel <[email-masked]>
Date: Wed, 6 Apr 2022 17:08:40 -0600

After reviewing the BIMI Reporting draft:

https://datatracker.ietf.org/doc/html/draft-adams-bimi-reporting

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

---

From: "Brotman, Alex" <[email-masked]>
Date: Fri, 8 Apr 2022 12:18:49 +0000

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 <[email-masked]> On Behalf Of Tom Bartel
Sent: Wednesday, April 6, 2022 7:09 PM
To: [email-masked]
Subject: [Bimi] BIMI Reporting

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

---

From: Trent Adams <[email-masked]>
Date: Mon, 11 Apr 2022 15:54:08 +0000

All good questions… and I hope to see responses from receivers / mailbox providers / MUA operators interested in sending BIMI reports…

… but if it's unlikely anyone will be generating/sending BIMI reports… well… that'll help us focus our time on other activities.

Anyone out there looking to generate/send BIMI reports?

Curious,
Trent

From: bimi <[email-masked]> on behalf of "Brotman, Alex" <Alex_Brotman=[email-masked]>
Date: Friday, April 8, 2022 at 6:20 AM
To: Tom Bartel <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Bimi] BIMI Reporting

Tom, I have questions about how this would be counted (“aggregate” is vague). Once per recipient for the entirety of the inbox? In the web versions for active participants, the logo shows only when the message is opened. In mobile, it shows

Tom,

Thanks for the feedback.

Tom

---

From: Tom Bartel <[email-masked]>
Date: Mon, 11 Apr 2022 13:29:53 -0600

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 <[email-masked]>
wrote:

>    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?
>    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
>
> *From:* bimi <[email-masked]> *On Behalf Of * Tom Bartel
> *Sent:* Wednesday, April 6, 2022 7:09 PM
> *To:* [email-masked]
> *Subject:* [Bimi] BIMI Reporting
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-adams-bimi-reporting__;!!CQl3mcHX2A!R06xZr6hwSAFSpSZ8V7DUzSjr9LHJ6z5gGQTn-w0XPV_AiVHqAGmmAIvC3wly4lKgKpggrQ$>
>
>
>
>
> that is, not only implementing DMARC, but the additional effort of
> implementing BIMI, too.
>
>
>

-- 
Phone: 303.517.9655
Instagram: https://instagram.com/bartel_photo

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