get_contacts with status => 'OPTOUT' not returning all results

SOLVED
Go to solution
Regular Participant

get_contacts with status => 'OPTOUT' not returning all results

 Some odd things going on with the API when I call get_contacts.

 

From inside the app it says I have 1449 active contacts, 43 unsubscribed ones, and 1670 total contacts. There are 178 contacts missing.

 

Though the API, when I call get_contacts(:status => 'ACTIVE') I get 1449. When I call it with OPTOUT, I get 43, and then when I call it with REMOVED, I get over a thousand.

 

Oddity number 1: the list returned from REMOVED has a ton of entries with status OPTOUT.

 

Oddity number 2: If I look through the list returned from REMOVED, and look for a status of OPTOUT, and a status of OPTOUT in the email address as well, then I find 177 entries. Those are the entries that are being displayed in the app when I select all contacts. Why are these contacts showing up in the app, or why am I not getting them with my status => OPTOUT query?

 

That only finds 177 results, I'm not sure where the other 1 result for a total of 178 is coming from.

1 ACCEPTED SOLUTION

Hi Jonathan,

 

Definitely some great questions here that are obviously confusing.  I forwarded your question about our new Contact Management System (CMS) UI discrepancy to the Product Manager for that product.  She will be able to answer that question much better than I can.

 

On the API data, there are some really small nuances that cause this to show up like this in how the data was organized in our older CMS and in the new CMS (which you are on). 

 

In the older CMS, Contacts had a Status field that contained these options: ACTIVE, REMOVED, UNSUBSCRIBED, AWAITINGCONFIRMATION.  A Contact could only have one of these statuses.  There was no overlap and thus it was very state machine oriented.

 

In the new CMS, a Contact can have a status of ACTIVE, UNSUBSCRIBED, AWAITINGCONFIRMATION or NOPERMISSION.  A Contact can also be soft deleted (removed) which is not the status but a state of the record.  Thus, there is now overlap between REMOVED and all the other states.  You can soft delete an unsubscribed contact, which means that contact is now both REMOVED and UNSUBSCRIBED and will show up in both filters.  Same can be said about all the other statuses except for ACTIVE, which can't be REMOVED. 

 

To make matters a little more complicated, the UI does not take into account any Contacts which are soft deleted (Removed).  It does not allow you to see them, manimpulate them or even know they exist.  Behind the scenes they all do and there is some matching logic if you import that contact again to match them up.  In order to provide a more predictable and usable REST API, we decided to show developers all of these deleted contacts to both retrieve and upate them if needed.  This is why the UI and API numbers will not even match up exactly.  The UI is a subset of the API, with the API providing a level of detail which is missing in the UI.

 

Hope this helps.  Our PM of Contacts should be posting some additional information about the UI discrepancy (or sending it over to me to post on her behalf).

Dave Berard
Senior Product Manager, Constant Contact

View solution in original post

5 REPLIES 5
Regular Participant

Anybody care to weigh in on this?

 

Really this is not only a question of the API, but a question of the accuracy of the data being displayed in the application as well. I don't trust either based on this example.

Hi Jonathan,

 

Definitely some great questions here that are obviously confusing.  I forwarded your question about our new Contact Management System (CMS) UI discrepancy to the Product Manager for that product.  She will be able to answer that question much better than I can.

 

On the API data, there are some really small nuances that cause this to show up like this in how the data was organized in our older CMS and in the new CMS (which you are on). 

 

In the older CMS, Contacts had a Status field that contained these options: ACTIVE, REMOVED, UNSUBSCRIBED, AWAITINGCONFIRMATION.  A Contact could only have one of these statuses.  There was no overlap and thus it was very state machine oriented.

 

In the new CMS, a Contact can have a status of ACTIVE, UNSUBSCRIBED, AWAITINGCONFIRMATION or NOPERMISSION.  A Contact can also be soft deleted (removed) which is not the status but a state of the record.  Thus, there is now overlap between REMOVED and all the other states.  You can soft delete an unsubscribed contact, which means that contact is now both REMOVED and UNSUBSCRIBED and will show up in both filters.  Same can be said about all the other statuses except for ACTIVE, which can't be REMOVED. 

 

To make matters a little more complicated, the UI does not take into account any Contacts which are soft deleted (Removed).  It does not allow you to see them, manimpulate them or even know they exist.  Behind the scenes they all do and there is some matching logic if you import that contact again to match them up.  In order to provide a more predictable and usable REST API, we decided to show developers all of these deleted contacts to both retrieve and upate them if needed.  This is why the UI and API numbers will not even match up exactly.  The UI is a subset of the API, with the API providing a level of detail which is missing in the UI.

 

Hope this helps.  Our PM of Contacts should be posting some additional information about the UI discrepancy (or sending it over to me to post on her behalf).

Dave Berard
Senior Product Manager, Constant Contact

View solution in original post

Spoke with our PM about the UI discrepancy you saw.  Here is the explanation I got from her:

 

In the new Contact Management System, Contacts are not required to have an email address and some, though infrequently, can have multiple email addresses.  Contacts without an email address will not appear in the "Active" or "Unsubscribed" lists as they don't have an email address.  However, you can still see these Contacts in the "All" view and if you export them you can see this.  Contacts with multiple email addresses can, on extremely rare occations, be in both "Active" and "Unsubscribed" if they chose to opt out one of their email addresses but not the other.  Since very few Contacts have multiple email addresses today, this is a very rare condition.

 

Also, there is a new type of Contact in our new CMS that did not exist in our old one.  This is a Company Contact record.  A Company Contact record is created automatically on imports whenever one or more Contacts have a Company Name set.  This will create a record that relates all of the Contacts with that Company Name to together for sorting and searching.  You can still see these Company Contacts in the "All" view but they don't have an email address by default, so they don't appear in "Active" or "Unsubscribed". 

 

You can see all of these types of contacts by sorting by the "email address" column or by exporting all your contacts and doing various searches or filtering in Excel. 

Dave Berard
Senior Product Manager, Constant Contact

Ok thanks, that explains it. I figured it was something like that, it's just super confusing because you can't really piece the full story together from the UI. The metrics I report in my app must match the ones in your UI exactly, otherwise customers would complain.

Certainly understand that and if you have any more questions, don't hesitate to ask.  We're working through the final migrations of accounts on our side.  Once we do that, we will be adding additional functionality to the API and, as always, will continue to update and refine our UI experience to match customer feedback. 

Dave Berard
Senior Product Manager, Constant Contact
Developer Portal

View API documentation, code samples, get your API key.

Visit Page