Feature Selection Based on Audience’s Behavior: Solving Social Media Information Overload
Feature Selection Based on Audience's Behavior for Information Filtering in Online Social Networks
The paper introduces a situation-aware feature selection method for information filtering in Online Social Networks (OSNs). By analyzing audience behavior through questionnaires and WEKA-based attribute evaluation, it identifies key features—Topic, Situation, and Relationship—to mitigate information overload and surpass the limitations of current chronological or simple EdgeRank-based feeds.
TL;DR
This research addresses the growing "information overload" problem on Online Social Networks (OSNs) by proposing a context-aware filtering mechanism. Unlike Facebook or Twitter, which rely heavily on time or simple interaction history, this study proves that the audience's current situation (e.g., in a meeting vs. at a party) and the topic of the post are the ultimate deciders of whether content should be displayed.
Background Positioning
In the academic coordinate system, this work sits at the intersection of Information Filtering (IF) and Context-Aware Computing. While prior SOTA methods focused on "Content-based" or "Collaborative Filtering," this paper moves towards a Hybrid Situational Approach, emphasizing that the audience, not just the content creator, should be the center of the information ecosystem.
Problem & Motivation: The Failure of Chronological Feeds
The authors argue that current feeds are "blind."
- Chronological Order (Twitter/Google+): Floods users with updates regardless of relevance.
- EdgeRank (Facebook): Focuses on affinity and time decay but ignores that a user’s "Solitude" or "Meeting" status changes their receptivity to content.
The core insight is that Information Overload isn't just about volume; it's about contextual inconsistency. An advertisement for a game might be fine on a Saturday night but is "eye pollution" during a critical project meeting.
Methodology: The Core Architecture
The authors propose a dual-stage system:
- Training Phase: Collects raw data from OSNs and users (schedules, contact roles), extracts features, and uses a Feature Selection module to discard noise.
- Test Phase: Uses a data mining algorithm (like Naïve Bayes or Decision Trees) to classify new posts as "Allow" or "NOT Allow" based on the refined feature set.

The Seven-Feature Hypothesis
The study initially proposed seven features ( to ):
- : Current Situation (Meeting, Private, etc.)
- : Topic (Sport, Music, Ads)
- : Relationship Type (Boss, Family, Friend)
- : Affinity scores
- : Popularity and Time Decay
Experiments & Results: What Actually Matters?
Using WEKA’s GainRatioAttributeEval, the authors ranked these features. Surprisingly, the industry-standard "Time Decay" () was found to be the least influential for user decision-making, despite being a staple of current OSN algorithms.

Critical Findings:
- The "Review" Correlation: Users who intend to review a post 2-9 times are likely to "Allow" it, but interestingly, those desiring to review 10+ times often "Disallow" it to avoid boredom or privacy exposure.
- Occupational Bias: Engineers are 90% likely to disregard family posts during "Code Programming" situations, but welcome them during private time.
- The Ad-Rejection Rate: 93.22% of participants rejected "Part-time job" ads while in meetings.

Deep Insights & Critical Analysis
Summary
The paper successfully demonstrates that three features—Topic, Situation, and Relationship—are sufficient to build a highly effective filter. This simplifies the computational overhead for future mobile-centric OSNs.
Limitations
The study relies heavily on self-reported questionnaire data, which can suffer from cognitive bias versus actual real-world behavior. Additionally, the "Current Situation" feature requires users to provide their schedules, raising significant privacy and manual-effort barriers for the average user.
Future Prospect
To make this practical, future research should focus on Automated Context Sensing. Instead of manual schedules, the system could use GPS, calendar API integrations, and ambient noise analysis to determine if a user is in a "Meeting" or at a "Party" automatically, applying these filters in real-time.
