Detect Recently Removed Reviews Without Full-History Scans

I’d like to share a possible approach for developing this feature in a way that does not significantly increase infrastructure costs.

From what I can tell, detecting removed reviews would require full scans across the entire review history, because the only way to know whether a review was deleted is to check whether it is still published at the source. I understand that doing this frequently for all reviews, across all accounts, could become very expensive.

However, it looks like there may already be a way to detect at least recently removed reviews without any additional full scans.

My understanding is that the current sync process seems to fetch recent reviews, rather than re-scanning the full historical dataset every time. I cannot confirm the exact implementation, but I believe it may not only fetch reviews since the last sync, but rather reviews from “some time back”. The reason I say this is because I noticed that some reviews inside EMR were previously marked as responded, but now appear as not responded.

After checking the source, I found that those reviews had actually been removed from Google Places / Google Maps.

This is a very interesting signal. If a review was previously known by the platform, was previously marked as responded, and later the response is no longer detected during the normal recent-review sync, that may already be enough to infer that the review was likely removed / deleted, without requiring any extra full-history scan.

So, at least for recently deleted reviews, this feature may already be technically feasible with little or no additional infrastructure cost.

Of course, this method would not be 100% complete. Very old reviews deleted long after they stop appearing in the “recent reviews” sync window would probably not be detected this way. But the key question is:

Is it better to have a system that detects recently deleted reviews, even if it is not perfect, or to have no system at all?

In my opinion, a partially complete but cost-efficient solution is much better than no solution.

A possible implementation could be:

• Detect reviews that were previously known in the system but are no longer consistently present in the source during normal recent syncs

• Mark them with a status such as Removed / Deleted

• Use that status across the product

Once that status exists, it would already unlock a lot of value:

• Filter reviews that were removed / deleted

• Exclude them from analytics and review counts

• Exclude them from the “pending response” filter

• Exclude them from review display widgets

• Improve accuracy across multiple parts of the platform

There could also be an optional complementary layer to improve historical completeness, although this would involve additional infrastructure costs.

For example:

• Add a button to scan the full review history for removed reviews

• Limit its use to once per month, if triggered manually

• Or run it automatically once per month, if deemed acceptable from an infrastructure-cost perspective

This is not intended as an alternative to the low-cost method described above, but rather as an optional way to improve accuracy if the developer wants this feature to get closer to 100% historical reliability.

In other words, the current sync behavior already seems capable of detecting recently removed reviews without requiring additional full-history scans. If considered technically and economically feasible, a monthly full-history scan could then act as a complementary verification layer for older deletions that would otherwise fall outside the recent-sync window.

I fully understand that this additional full-history scan may not be desirable because of the extra cost, so I am not suggesting it as mandatory. That part should of course be evaluated by the developer.

The main point of this feedback is that there already appears to be a low-cost path for detecting recently removed reviews, using signals that seem to be surfaced by the current sync behavior (Specific example with images shown below).

If you want to upvote the actual feature request, please do so here:

https://roadmap.embedmyreviews.com/en/p/dashboard-not-synced-when-a-review-is-deleted-on-google

Now let me give a practical example of how the current system has already “caught” the removed/deleted reviews:

I have one client with around 100 Google Business Profile reviews, receiving roughly 5 to 7 new reviews per month. The client responds to all Google reviews. Inside EMR, if I go to the reviews section and apply the filters:

• Source = Google

• Response Status = Pending

The reviews that appear there are, in practice, the reviews that were removed / deleted, because all Google reviews are actually responded to.

Below I’m including:

• the link to that client’s Google Business Profile

• a screenshot of the reviews shown as “not responded” inside EMR

In that screenshot, those “pending” reviews are basically the reviews that were deleted / removed, except for the last 3 reviews from C.M., Gabriel Rodríguez, and Elizabete Nogueira, which are genuinely still present in the GBP and are in fact not responded to.

That seems to indicate that the current sync logic is already capable of surfacing the absence of previously known review-response data. If so, then it may also be possible to infer that the review itself no longer exists at the source.

There may be some technical detail I am missing, but at first glance this seems feasible.

Link to this customer GBP: https://maps.app.goo.gl/8m55LxyiBH2ryP2U8

(Order the reviews by most recent after clicking the link)

Image within EMR displaying all the reviews that were deleted or removed: