My journey into recommendation systems started with curiosity: how do large companies decide what to recommend to each user? While exploring their approaches, I wanted to understand how similar ideas could be applied to associations and their members.
Exploring the approaches
I started by learning about the different ways recommendations can be generated:
- Content-based filtering: Suggest items based on their similarity to a person’s interests or previous choices.
- Collaborative filtering: Use patterns across users, such as what people with similar behavior have selected.
- Hybrid approaches: Combine multiple methods to make recommendations.
- Graph-based recommendations: Use relationships between people, topics, and offerings.
- Semantic similarity: Match the meaning of interests and item descriptions, even when they use different words.
My first learning was that the approach should follow the available data and business needs. There is no single algorithm that fits every recommendation problem.
Building a common data foundation
Different associations use different systems, field names, and structures. Building recommendation logic directly around each source would make it difficult to reuse.
To address this, a Canonical Data Model (CDM) was chosen: a shared representation of concepts such as members, memberships, courses, and events. Each association’s source data is mapped to this model.
This provides a consistent foundation while allowing association-specific mappings and rules.
Connecting the data through Neo4j
The next step was representing the standardized data as a graph in Neo4j. The overall flow became:
Source data → (Medallion Architecture) CDM(Gold Schema) → Neo4j → Recommendation pipeline
The CDM defines the common concepts and relationships. Neo4j stores their graph representation as nodes and relationships, making those connections queryable.
For example, the graph can connect a member to their specialty and connect courses to relevant subject areas. These relationships help identify potential courses for that member.
A key learning was that storing data in a graph does not automatically produce useful recommendations. The recommendation pipeline still needs rules for selecting candidates, checking eligibility, and ranking results.
Starting with course recommendations
I focused the first implementation on courses to keep the scope manageable.
The pipeline uses member context to find candidate courses, removes duplicates, checks eligibility, and ranks the remaining options. Graph relationships, semantic similarity, and learning-level readiness contribute to this process.
A course may match a member’s specialty but be too advanced for their current learning stage. Combining signals helps account for these different aspects of relevance.
Short explanations, such as “Matches your specialty,” also help members understand why a course was suggested.
What I learned
Building a recommendation engine involves more than choosing an algorithm. It requires consistent data, meaningful relationships, clear business rules, and validation against realistic member profiles.
Starting with courses helped me understand the complete flow. The CDM and graph foundation also provide a path toward supporting other association offerings, such as events and certifications.
Top comments (0)