MATCHMAKING APPCase study of Miggly project

OVERVIEW

• The purpose of this application is to build a tool “Where Friends Match Up Single Friends”

• Anyone having a valid Facebook account can register on Miggly as either “Single” or “Matchmaker", where “Single” is the one who is looking for the perfect match and “Matchmaker” is the one who is interested in helping their other single friends in finding the perfect match

• For “Single Role”, the user should be able to invite their Facebook friends as their “Matchmaker” and hence to see the “Single” friends of the “Matchmaker” based on their preferred gender and then to “Say Hi” to the perfect match

• They should be able to create “Dating Games”, which is nothing but asking questions (a maximum of 5 questions per game) within a group of minimum two and maximum four singles

• Singles should be able to see their Facebook likes regarding Music, Video, Books on their profile page and it should be always updating based on the changes on Facebook

OVERVIEW

• For “Matchmaker Role”, the user should be able to invite their Facebook friends as their “Singles” and hence to “Match Up” those with their other “Single” friends based on the gender preference

• Matchmaker can also invite their Facebook friends as their “Matchmaking Helper” and by boosting their network of “Single” friends for “Match Up”

• Matchmaker should also be able to create “Dating Games” for their “Single” friends

• Matchmaker should get notifications based on their Single’s activities • Matchmakers should be able to see their “Single” friends on their profile page

based on their “Single Friend’s activity on Facebook”• Both “Single” as well as “Matchmaker” should be able to upload photos and can

have different custom photos based on their roles • All the photos should be approved by the administrators before it can be

viewed by others• Miggly will be using re-marketing emails to get their users back into the system

based on certain criteria; especially when they were not logging in back for a period of time

CHALLENGES

• Allowing the user to register with a valid Facebook login and automatically logging into Miggly if the user is already logged in to Facebook and has a valid account on Miggly.

• Always keeping the friends list updated on Miggly with Facebook.• Handling of different types of Facebook Requests/callbacks.• Updating the “Relationship Status” changes on Facebook into Miggly.• For Matchmaker role, to keep their Friends list on profile page always updated

based on the Facebook activity of their friends.• Identifying the Miggly users when they de-authorize the “Miggly App” from their

Facebook account and to avoid authorization related problems when using “App Request on Facebook”.

• Identifying the Miggly users who have de-activated their Facebook account; to avoid sending any message/request to their Non-Existing Facebook account.

• To prevent the un-authorized viewing of content by other users of Miggly.• To reflect any changes in the profile picture on Miggly emails after the email

delivery was made.

CHALLENGES

• Identifying the number of successful logins based on the user’s role to show the “Miggly Tour” without affecting the performance

• Displaying of user’s Facebook likes regarding Music, Videos & Books• Dynamically displaying of “Notification Messages” on users Home Page & LOVE

Page with multi-language support• Automatic Allocation of Miggly Badges and the provision to verify the same.• To approve the photos uploaded by the users• To manage the “User Reports” and hence to suspend the users’ account if necessary• Handling of Miggly Emails and Tracking • To bring user back to the system if they are not active for a period of time• To testing the re-marketing emails to verify the delivery, copy, layout, etc• Processing of various kinds of request by clicking on the buttons from Miggly emails• Auto Processing of request followed from Facebook notification/message links

SOLUTION

• FACEBOOK LOGIN• In Miggly, we have implemented a combination of JavaScript & PHP SDK to

connect the users with Facebook and hence to access the system. The login part was handled by JavaScript SDK and the post request callback was handled via PHP SDK to complete/validate the login and hence to allow/deny the user to continue with the application.

• UPDATING FACEBOOK FRIENDS (ALWAYS)• One of the challenge was to keep the Facebook Friends list updated within the

miggly system. There could be a possible delay in taking the user to his/her home page as it required to update the FB friends list during every login; depending on the number of friends they dely could vary. After done with the R&D, we have provided the best solution which uses the “ETag” information provided by Facebook that will help us to identify if there are changes in the user’s friends list on Facebook. This helped us to avoide the checking unwanted and thus to improve the performance.

SOLUTION

• FACEBOOK REQUESTS• In Miggly, we need to send many kind of requests to user's Facebook

account and most of the request will have certain action/functionality involved if the user happened to click the link. It was “true” that the FB API will redirect all request to a single URL and we cannot configure multiple callback URLs. As a result, it will be verify difficult for the developer / QA to verify these requests as it would require us to copy /paste the URLs to work with different platforms

• We have implemented a logic such that the Redirect URLs created on Facebook will hold a reference that will help us to identify the platform from which the request was generated. Once the user click the link from their Facebook account, it will redirect to the callback URL and there our system will identify the actual platform to which the request belongs to and then the Miggly System will redirect the request to the correct platform. This helped us to avoid the copy/paste URLs from Facebook request redirection and hence to save the developer/QA time

SOLUTION

• UPDATING ‘RELATIONSHIP STATUS’ CHANGES• One of the major role in miggly is “Singles” and it is very important to track any

changes to the users’ Facebook Relationship Status • It was “true” that there is “NO” direct way of identifying such changes on

Facebook account • To overcome the situation, we have followed the same “ETag” logic that we have

implemnted to update the friends list• However, we have enhanced the logic such that any change in the “Relationship

Status” of the user will be updated into Miggly in two ways:1. During the very next login by the user after the “Relationship Status” was

changed on their Facebook account2. When one of his/her friend is trying to login to Miggly after the

“Relationship Status” was modified by their friend• As we used to capture / update the “Relationship Status” in two different ways, it

will make sure that the user’s “Relationship Status” will be immediately updated if someone happened to see/visit the Miggly profile

SOLUTION

• SORTING FRIENDS BASED ON FB ACTIVITY (PERMISSION BASED)• In Miggy, for Matchmaker role, it was required to sort the friends list on the

users’ profile page based on the Facebook activity of their friends and there was not direct API available in Facebook to achieve this task

• We have built a custom solution, which will crawl the user's notification (latest 10) and hence to build a sorting index based on the number of occurrence of their friends

SOLUTION

• HANDLING OF ‘MIGGLY APP’ DE-AUTHORISATION• While using Facebook Apps, it was a challenge to identify the users who were

de-authorized the application from their Facebook account • This caused a problem when we try to send the messages to the user’s

account using “App Message”• After doing the R&D we decided to use the FB API’s “De-authorization

Callback” functionality to overcome the situation • We have implemented the logic such that on receiving the de-authorization

callback, Miggly system will be marking the user’s account and hence to avoid using the “App Message” while sending any future message to the user’s Facebook account

• It is noted that the new logic we have implemented will update the user’s account status across the platforms with the single callback function

SOLUTION

• HANDLING OF ‘MIGGLY USERS’ WITH DISABLED FB ACCOUNTS• In Miggly, we are sending various kinds of message / notifications to the user’s

Facebook account• While sending the message to the user’s Facebook account, there are

exceptional case in which the user might have deleted / disabled their Facebook account; in such case, Facebook used to through an error message as the user account does not exists and was caused a problem in completing the desired action

• We have implemented a new logic that will work as a “PRE Check” to whether the user’s accounts is valid on Facebook or not.

• If it is found that the user has disabled their FB account, the Miggly System will show the message to the user to let them know that the other user’s Facebook account does not exist and also at the same time the other user’s Miggly account status will be marked so that the user’s account will not be shown in Miggly until they re-visit the Miggly system again

SOLUTION

• PREVENT UNAUTHORISED VIEWING OF ACCOUNT• Once of the biggest challenge in any of the web-based application is to

prevent the un-authorized access of other’s data/content by copy/paste URLs• In Miggly, we have implemented the logic to cross verify to identify whether

the user is authorized to view the particular data belongs to the other user and if “NOT” the user will be redirected to either his own home page or other related page; thus completely preventing the un-authorized access of user’s data and hence to increase the privacy of the user

SOLUTION

• SHOWING UPDATED PROFILES ON MIGGLY MAILS• Miggly delivers a number of emails to its user ; these email may contains the

profile images of other Miggly or Non-Miggly users• For the case of Miggly user ; they can change their profile images any time

based on their roles • In such occurrence, the new image will not be reflected in the emails delivered

in the past • To overcome this issue, we have created an API to display the user’s profile

image dynamically inside the emails that are generated by the Miggly system; thus ensuring the latest profile image to be displayed always in emails even if the delivery happened in the past

SOLUTION

• LOGGING IN (BASED ON USER ROLE)• In Miggly, we have to display a “Tour” based on user’s role during their first

seven login attempt• This tour is used to help / guide the user the basic functionality of the system

as they are new • This required us to keep track of the user’s successful login attempt and the

challenge in implementing the system was to ensure that this logic will not cause any trouble in the performance of the system especially the logging-in time. We have implemented a login-log system as 1:1 (one row per user) as we required to query this table during every login

SOLUTION

• FACEBOOK LIKES• In the profile pages of Miggly Singles, we have to display the Facebook likes

regarding Video, Music and Books and it should always display the latest information from the users Facebook account

• After the R&D we have implemented a live crawl for reading the latest users’ likes; thus ensuring the data displayed on Miggly to be always updated

SOLUTION

• MIGGLY BADGE ALLOCATION• One of the features of Miggly is “Allocating Badges” to the user based on

their “Role & Activity” and each user role can have a maximum of 21 badges hence there can be 42 badges per user

• For the better performance, we have decided to approach 1:2 (one user two rows) i.e.. one row for each role

• This helped us in reducing the number of rows in the main table and hence to increase the performance of the system

SOLUTION

• MIGGLY NOTIFICATION HANDLING• One of the biggest challenges in Miggly was to handing the various kinds of

messages/notifications displayed in the user's home page and especially in the love page

• In the love page of the single user, the notification text will be changing based on the visitor’s role

• To give the optimum performance, we have decided to store only one entry in the database and then to change the notification text based on the visiting user's role

• In addition to this some of the notification are not shown to a specific role (either self, matchmaker or other matchmaker) this become a complex in retrieving the notifications from the database

• We have implemented a logic to validate the notifications after reading it from the database and before displaying it in the page based on the user’s role

SOLUTION

• PHOTO APPROVAL TOOL• Miggly allows the user to upload photos and it was highly important to screen

the photos before it can be viewed by others• We have created a tool for photo monitoring and the tool requires

authentication for accessing it• This tool will list all the photos uploaded by the users based on Today, This

Week, This Month, etc. • The administrator can approve, warn or suspend the user once after verifying

the same and all is done by a single click • If the administrator warns the user, an automatic email will be send to the user

and during the 4th warning, the users account will be blocked automatically• In addition to the flexibility we have provided in this tool, it was built with a

tracking of all administrator activity especially when the warn/suspend the user for any future audit purpose

• The data is stored in a stats table that can be queried accordingly

SOLUTION

• REPORT USER TOOL• Miggly allows the users to report others profile if they find some data to be

abusive• We have provided a system for monitoring all user reports so that the

administrator can verify take necessary action to suspend/un-suspend the users account

• We have also given the search option so that the admin can easily find the user by simply typing the search words into the search box.

• Also provide a custom filtering option to display the result based on Today, This Week, This Month, etc.

• In addition to the flexibility we have provided in this tool, it was built with a tracking of all administrator activity especially when the warn/suspend the user for any future audit purpose

• The data is stored in a stats table that can be queried accordingly

SOLUTION

• HANDLING EMAIL via MANDRILL• Miggly uses emails for re-marketing purpose and a large number of emails

were send automatically based on the criteria• It is very important to have a system to track the delivery of the emails and

also to identify the number of users who have opened/read the mail• After the R&D we have decided to proceed with the MANDRIL with is a 3rd

party service; a free email tracking tool for 12K emails per month • This tool includes the complete tracking including the deliver and read/unread

status, etc.

SOLUTION

• REMARKETING EMAILS• One of the biggest challenge in Miggly is to bring the user back to the system

when the are idle for a week, month, etc. • We have implemented automated email (remarketing email) delivery system

with necessary information to increase the possibility of bringing the user back and these emails will be send automatically via CRON (running of automated scripts on schedule basis) running on server

SOLUTION

• TRAILMAIL TOOL• One of the difficult part while using the re-marketing email was the “wait

time” as the emails will be generated only once the days, weeks, etc. is reached• We have provided a tool to the client for manually generating all the

remarketing emails by simply inputting the desired user’s email as an input• The tool also contains an alternate email address that will allow the

administrator to receive the email in a secondary email inbox. This tool helped the developer/QA to save their time in receiving the email to verify the layout, copy, body, etc.

SOLUTION

• CTA BUTTON REQUEST PROCESSING• The mails generated from Miggly system will also include CTA (Call To Action)

buttons • Once the user clicks the button, the user should be re-directed to Miggly and

hence to complete any action/activity associated with the same • It was a challenge when implementing the logic such that the user may be

already logged into system with a different role which is NOT associated with the CTA button action

• We have implemented a logic to automatically switch the users role to the desired one before start processing any further action hence to the successful completion of the request

SOLUTION

• REMOVE DATA TOOL• During the development/QA it was found very difficult to test various action

as most of the actions were one time activity (example registration) • As Miggly works completely with Facebook credentials, it was verify difficult to

create Facebook account to check every kind of development/QA activity• We have suggested a tool that will allow to remove/clean all user related data

from the Miggly system so that to re-use the Facebook account again and again

• This helped us in saving the developer/QA time very much

SOLUTION

• OPTIMISING PERFORMANCE• During the implementation of Miggly, the a primary goal was to ensure the

optimized performance of the system. • We have studied / analyzed the system considering various use case and

designed the Database accordingly to avoid the maximum possibility of reducing the over all load to each and every table

• To achieve this, we have decided to separate the table into two blocks one for the regular use with the system and the other is to used to store the logs, which can be used for any stats activity

• We have also used the DB TRIGGERS in the best possible way that will help us to reduce the Web-Server load

SOLUTION

• THE MIGGLY SYSTEM• The Miggly System was about to change based on the market study and the

other factors involved in the market and the initial requirement was to expect frequent changes to the system including logic and functionality.

• It was a challenge for the developer to handle this as you can understand the difficulty in handling frequent changes in any system

• To overcome the situation, we have decided to build a system based on “Templates & Component” basis so that we can reuse the component by “Plug & Play” the templates/modules easily from one plays to the other.

• This decision helped us for the maximum possibility of reusing existing components and hence to avoid too much of reworks

• In other words, it helped us to minimize the rework to at least some level