Let's move that conversation to another ticket, once the texting contract is signed. Then get back to this ticket after that.

So you will be moving to an non-email keyed database as yo are adding SMS/MMS to Acoustic. That won't change much about this project, but I might wait until that is complete. The only real difference for this part is you will sync on your Civi CRM, not email address.

Confirmed access is working

So suspect I know what happened, it struck me you said the email is not in Acoustic anymore. My guess is Civi merged two records - and in the process deleted the record the email was sent to. (which is a bigger issue if you are removing emails from the list, but that's for another ticket) When the user clicked the link the personalization failed, as the record no longer exists. I suspect this is pretty edge case then. But, you could turn off link tracking on these emails, which would then populate the URL in the email itself at the time of send. That way even if Civi updates the record in Acoustic, the link in the email would be static. Is that change warranted for this kind of edge case I don't know, as you will lose link tracking data.

No humans ever see the text version, so it's not that. If if they seeing the text version they are using some kind of crazy mail client that could be alerting links.

We have access to Google Postmaster Tools, this is just with a new account that will allow us to send automated alerts based on a Spam Rate threshold, and alerts if Domain reputation changes or their are Delivery Errors.

In theory, yes you could do this, but it would require updating to a non-emailed keyed database. This would be a huge undertaking. Might be worth an investigation on your part, but would require a significant re-architecture of your integration and email program.

Those three fields are updated by Acoustic nightly (under Settings -> Organization Settings -> Automated Behavior Updates). You can export these fields as you can any other field.

More context. There are three types of suppressions (System, Org, Mailing). System suppressions are domains that are suppressed on all of Acoustic as they are not real, spam trap, generic garbage. Org level are the Master Suppression List, and Mailings level is when someone added a Suppression List at the time of send.

This was related to something @KHaggard sent me an email on, and that a large suppression list was added at the time of send.

Turns out it's not possible to export specifically the snoozed contacts. You have to ExportList and download the entire database, they are included and the "Opted Out" column will be populated with an S. It might make more sense to add Snooze to your unsubscribe page/preference center and go from it that direction.

In Acoustic under Show Additional Details within the database, the number of Snoozed records is 4,507. In the web interface, exporting SNOOZE only is an option, so suspect we just need to know the correct element name. I'm asking what that is.

The user you export data with is set to GMT. I checked data in some of our accounts and it's being exported as GMT. Can you provide some examples where you are seeing PT in the exported file? Is this something recentlly that changed or it's been like this for years?

@Eileenmcnaughton Not having an email in the upload should not have stopped the Contact List from being built. What API calls are you making and with what parameters?

No real person should have that as their email address, I would leave it and opt the user out.

Something struck me on how you can get this data. If you run this API call each day:

Both, you can see who is snoozed in the UI and via an API export - but you can't get the date.

You can export the current list of Snoozed records (which is currently 15,882) but not the date they will become un-snoozed.

SENT_CANCELLED does not do anything with GetSentMailingsForOrg. What is the mailing ID of the canceled mailing?

Your data retention policy is set to 450 days, you can see this under Organization Settings -> Archive Settings. I'll have to test that specific question. I would suggest you should cap all data at 90-120 days, anything after that is likely not real user activity, and has no chance of substantially changing the data. Frankly, I suspect if you had a cutoff of 60 days (or even shorter) that would capture 99.8% of all your data.

I'm hoping once you get rid of all the extra databases, this issue will no longer occur. As this seems to never happen with the main database. There is no reason to open Support tickets on these as they are aware of the issue.

Same issue as before. As this only happens with the non _All wiki DB, I'm hoping once these other DBs are removed this issue will be resolved.

I found an email from 2015 wher eI outlined this API call. I forgot there is an unpublsied elements called SENT_CANCELLED. I'll reforward the email.

Ah yes, remove <SENT/> and that will return all types, included Canceled.

Add List ID 9574332 and that should do it.

Ah... ok. So let's look at the specific API call. Need the full XML. Thanks.

(a) what is Superset? (b) what is the API call you are making, do you have the XML?

I have opened a case up on these two jobs.

No logs are stored more than four days (as that would not be GDPR complaint). I suspect you see the SUCCESS within 1-2 mins every time? Can you setup an alert that if don’t get that say within an hour, it sends us off an email?

Data job results are only retained for three days, so I can ask, but don't expect there is more infomraiton.

With an average of 68 GDPR data calls in the last three days (and the numbers are sequential) , that would make that ID around 50 days ago. Does that make sense?

That ID is a bit confusing. The current GDPR data job are IDs 33341 -> 33546, which all ran in the last three days and all are marked SUCCESS. Thought maybe this was a datajob ID, but that range is 173051574 -> 173776347. What was the API call make with this ID and when?

A 3% is normal for Verizon (aka, AOL/Yahoo). When I see blocks at Verizon it will be 100% soft boucning.

You want to build this report by domain group, not domain. Example, RoadRunner no longer exists, it is now part of Spectrum Communications. I will build a mapping for domains -> domain groups to use.

Each GDPR job has several subtasks. The job may get stuck after completing the subtask. This is a known issue. If a GDPR job does not complete within 60 minutes, just let me know and we can dig into it.

I'll have to ask if there are more details on the failures. When you get one that failed, are you able to re-run it? Did you mean the two from July 2019?

Also, I recommend you merge all your data into a single database to simplfy GDPR requests. There are seven databases right now, and ten suppression lists.

Reading back over the previous notes, wanted to mention "I realize RML contacts should have civi contacts" - there are several hundred thousands RML signups that are not in Civi. Some are historical, and some are recent. I'm unclear how you are getting RML contacts out of Acoustic into Civi, but happy to help debug that if you want.

Can we take one step back and sanity check that the Civi database has all the data from the Master Suppression List? I'm assuming (and this might be wrong) that there are emails on the Master Suppression List that are not marked as opt-outed in Civi. When you export the MSL, select the “Export Contacts, Opt-Outs, Snoozes and Undeliverables” option.

Rebuilding the Master Suppression List is very risky, and I would not recommend it. Anyone on that list should never be emailed. If Civi were missing any data, that could be catastrophic to your deliverability.

"there's a way to import the list of suppressed contacts to the main db with opt-out selected so that it just updates the contacts that are already in the main db" - Are you referring to Civi or the Acoustic database? For sure you can keep this all clean in Acosutic, but over time it will get out of sync again.

A few notes to add. You can do anything mentioned here with the API, it's just up to you how you want to structure it. The link above about CRM integration does not apply here (that is for Acoustic accounts that sync with SFMC or MS Dynamics).

IBM validated the DNS setting, and is using the new key:

The key is correct, and IBM will validate it before turing it live. I would recommend in four months, you remove the old key.