Participants
Walker-Sperber, Ian , Silva, Carlos , Miguel-Romero, Almudena , Fernandes, Francisco , Bandoch dos Santos, Diego (Deactivated) , Raphael Ferreira Gomes
Context
Iberia (PLK) before RBI
Before Iberia joined the RBI International platform they had their own Android/Apple Guest App developed by another company (AirTouch). This app was connected to an specific Firebase instance and they didn’t have any mechanism to segment or filter users on this level.
To comply with GDPR and avoid sending PN (Push Notifications) to user that had not authorized communications they implemented a filter on the app to ignore notifications for those users.
* OBS: Most of the information here was captured with Iberia during conversations, but we never had access to schematics about this architecture.
RBI recommended Architecture
Based on the documentation available the recommended way to send push notification under the RBI International platform is adopting Braze as the communication tool. Under this architecture, a simplest way to see the solution is:
Iberia integration with Salesforce
Even with the recommendation from RBI the Iberia decided to adopt a different path. The proposed solution was to use the Salesforce Push Notifications framework that is connected to the Journey Builder and then given them ways to manage how their users behave and then send push notifications based on these user contexts.
Other point to opt for Salesforce is the time to market, they already had a contract signed with Salesforce and to sign another contract would take more time.
Blockers on the road: During the solution development the team found out 2 major blockers that wouldn't allowed them to proceed with this solution:
Lack of support from Salesforce: it seems that right now the SDK provided by Salesforce only support native apps (Android and Apple), so no support for hybrid solutions (Ionic + Capacitor) and other small details.
Capacitor upgrade: to make the app able to deal with push notifications for phones with Android newer than the 12 version the WL needs to upgrade its capacitor version from 2.5 to the version 5.
Iberia Workaround solution (Short Term)
Given the first solution proposed by Iberia isn’t possible right now and the pressure from the market we needed to came up with a intermediate solution that would given them at least some options to send notifications even minimal options. So we reassessed all the last solutions to make sure none of them is possible:
Firebase + App Filter: Implement the filters on the app would require native code. So we discarded this option.
Only Firebase (send notifications to everybody): GDPR restrictions. It can put Iberia in a bad situation in case users start complain about that.
Braze (recommended solution): it would take months until have the go-ahead from legal, compliance and other departments
Salesforce: no visibility on when the 2 blockers will be solved
Thus, we got a hint from Zaira on how we could comply with the requirement (send push notifications to users that had accepted to receive them) with the tools already in place. To send the notification we only have Firebase, but it isn’t able to segment or filter which users had accepted the communications. And here is where mParticle comes in place. Iberia is already using that and it has the users profile (communications) and the only information missing is the device token that is the part that could connect mParticle to the Firebase. So the proposed solution is something like that:
It is possible to see that there is a question mark on how Iberia will integrate with the users on the mParticle with Firebase. It is something that Zaira and Raul are trying to figure out how to solve. They are even evaluating if Salesforce can do this integration.
ALMU: At the same time, we need to ensure that Airtouch will be managing the sending of the push notifications as RBI will not onboard this responsibility. If needed, give Airtouch access to our Firebase instance
Decision
Based on the discussions that we had with the Market and the pressure from Iberia, it seems that the workaround is the only viable way to proceed given the time frame available. Any other option will take more time and even make other activation be delayed (BK PT and BK ES).
Consequences
As any other workaround this option is not sustainable for a long period. So, even it solves the current pressure, it will require the team able to carry on on the next implementation to find the definitive solution. In the other words: it solves for now, but will require more effort to really finishes.
Add Comment